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ABSTRACT 


Siram,  Nanditha  Nayani,  M.S.,  Purdue  University,  May  2002.  “An  Architeeture  for  the 
UniFrame  Resource  Discovery  Service”.  Major  Professor:  Rajeev  Raje. 

The  software  development  for  any  large-scale,  Distributed  Computing  System 
(DCS)  is  a  major  challenge.  One  solution  to  address  the  design  complexity  of  a  DCS  is 
the  "UniFrame"  approach.  UniFrame  provides  a  comprehensive  framework  unifying 
existing  and  emerging  distributed  component  models  under  a  common  meta-model  that 
enables  the  discovery,  interoperability,  and  collaboration  of  components  via  generative 
software  techniques.  This  thesis  presents  an  architecture  and  implementation  for  the 
resource  discovery  aspect  of  this  framework,  called  the  UniFrame  Resource  Discovery 
Service  (URDS).  The  proposed  architecture  addresses  the  following  issues:  a)  the 
dynamic  discovery  of  heterogeneous  software  components  which  offer  and  utilize 
services,  and  b)  the  selection  of  components  meeting  the  necessary  functional  as  well  as 
non-functional  requirements  (such  as  desired  levels  of  QoS  Quality  of  Service).  The 
thesis  also  compares  the  URDS  architecture  with  other  Resource  Discovery  Protocols, 
outlining  the  gaps  that  the  URDS  is  trying  to  bridge.  In  the  URDS  the  native 
registries/lookup  services  of  various  component  models  are  extended  to  be  ‘active’  (i.e. 
listen/respond  to  periodic  multicast  announcements)  and  also  have  introspection 
capabilities  to  discover  not  only  the  instances  but  also  the  specifications  of  the 
components  registered  with  them.  “Services”  in  UniFrame  are  implemented  in  different 
component  models  and  described  by  their  UniFrame  specification  outlining  the 
computational,  functional,  cooperational,  auxiliary  attributes  and  QoS  metrics.  The 
URDS  security  model  provides  for  the  authentication  of  the  principals  involved,  an 
access  control  to  multicast  address  resources,  and  an  encryption  of  data  transmitted. 
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1.  INTRODUCTION 


Component-based  software  design  has  been  a  growing  trend  in  the  development 
of  software  solutions  for  distributed  systems.  The  software  realization  of  a  distributed 
computing  system  (DCS)  is  typically  achieved  by  using  the  notions  of  independently 
created  and  deployed  components,  with  public  interfaces  and  private  implementations, 
loosely  integrating  with  one  another  to  form  a  coalition  of  distributed  software 
components.  Assembling  such  systems  requires  either  automatic  or  semi-automatic 
integration  of  software  components,  taking  into  account  the  QoS  (Quality  of  Service) 
constraints  advertised  by  each  component  and  the  collection  of  components.  The 
UniFrame  Approach  (UA)  [RAJOl,  RAJ02]  provides  a  framework  that  allows  an 
interoperation  of  heterogeneous  and  distributed  software  components  and  incorporates 
the  following  key  concepts:  a)  a  meta-component  model  (the  Unified  Meta  Model  - 
UMM  [RAJOO]),  with  a  associated  hierarchical  setup  for  indicating  the  contracts  and 
constraints  of  the  components  and  associated  queries  for  integrating  a  distributed  system, 
b)  an  integration  of  the  QoS  at  the  individual  component  and  distributed  application 
levels,  c)  the  validation  and  assurance  of  the  QoS,  based  on  the  concept  of  event 
grammars,  and  e)  generative  rules,  along  with  their  formal  specifications,  for  assembling 
an  ensemble  of  components  out  of  available  component  choices.  The  UniFrame  approach 
depends  on  the  discovery  of  independently  deployed  software  components  in  a 
networked  environment.  In  this  thesis,  an  architecture  and  implementation  for  the 
resource  discovery  aspect  of  this  framework,  called  the  UniFrame  Resource  Discovery 
Service  (URDS)  is  described.  The  URDS  architecture  provides  services  for  an  automated 
discovery  and  the  selection  of  components  meeting  the  necessary  QoS  requirements 
specified  by  a  component  assembler  or  system  integrator.  URDS  is  designed  as  a 
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Discovery  Service  wherein  new  services  are  dynamically  discovered  while  providing 
component  assemblers  with  a  Directory  style  access  to  services.  The  result  of  using 
URDS,  the  UniFrame  Approach  (UA)  and  its  associated  tools  is  a  semi-automatic 
construction  of  a  distributed  system. 


1 . 1  Problem  Definition  and  Motivation 


There  has  been  an  increase  in  the  development  of  technologies  for  the  dynamic 
discovery  of  resources  such  as  printers,  mail-boxes,  memory  space  and  disk  space  that 
are  available  in  every  network.  The  growth  in  the  popularity  of  portable  devices  such  as 
laptops,  PDAs,  and  cell  phones  which  require  configuration  each  time  they  attach  to  a 
new  network  segment  has  also  sparked  the  need  for  developing  protocols  which  facilitate 
spontaneous  discovery  and  enable  such  devices  to  connect  to  these  resources.  However, 
research  in  the  area  of  dynamic  discovery  has  been  focused  solely  in  the  area  of 
discovering  and  configuring  “devices”. 

There  is  a  need  to  bring  about  a  change  in  paradigm  from  dynamic  discovery 
being  purely  “device”  based  to  a  “service”  based  approach.  “Service”  here  refers  to 
applications  developed  using  different  distributed  computing  models,  with  public 
interfaces  and  private  implementation,  that  perform  computation  or  actions  on  behalf  of 
client  users.  Several  directory-based  approaches  exist  for  discovering  services.  These 
directory-based  discovery  services  are  built  around  the  publish-subscribe  model  wherein 
services  publish  their  interfaces  with  a  central  directory  and  clients  discover  these 
services  by  contacting  the  directories.  Prominent  among  these  are  Universal  Description, 
Discovery  and  Integration  (UDDI)  registry  [UDDOO],  CORBA  Trader  Services  [OMG 
00],  Java™  Remote  Method  Invocation  (RMI)  [ORF97],  Distributed  Component  Object 
Model  (DCOM™)  [MIC98],  etc.  However,  almost  all  of  these  directory/registry  services 
do  not  assume  the  presence  of  other  models.  The  interoperability,  which  they  provide,  is 
limited  mainly  to  the  underlying  hardware  platform,  operating  system  and/or 
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implementational  languages.  This  defeats  the  underlying  goal  of  diseovery  being 
universal. 

The  problem  that  needs  to  be  solved  is  to  provide  for  a  “service”  discovery  model 
that  is  dynamic  and  encompasses  services  developed  in  diverse  distributed  computing 
models. 

The  motivation  for  creating  a  universal  dynamic  resource  discovery  service  is  as 
follows:  The  software  systems  in  any  organization  constantly  undergo  changes  and 
evolutions.  Moreover,  these  organizations  may  be  geographically  (or  logically)  dispersed 
necessitating  a  communication  between  independently  created  and  deployed  components, 
loosely  integrating  with  one  another  to  form  a  coalition  of  distributed  software 
components.  In  order  to  deal  with  the  constant  evolutions  and  changes  in  the  software 
systems,  there  is  a  need  to  rapidly  create  software  solutions  for  distributed  environments 
using  a  component-based  software  development  approach.  The  solution  of  decreeing  a 
Common  Off  The  Shelf  (COTS)  environment,  in  an  organization,  will  require  creating  an 
ensemble  of  heterogeneous  components,  each  adhering  to  some  model.  If  reliable 
software  needs  to  be  created  for  a  DCS  by  combining  components,  then  the  quality  of 
service  offered  by  each  component  needs  to  become  a  central  theme  of  the  software 
development  approach.  Assembling  such  systems  requires  either  automatic  or  semi¬ 
automatic  integration  of  software  components. 

The  key  to  automating  the  process  of  assembling  DCS  is  to  have  an 
infrastructure,  that  allows  for  a  seamless  integration  of  different  component  models  and 
sustains  cooperation  among  heterogeneous  components.  Such  an  infrastructure  will  need 
to  provide  services  to  dynamically  discover  the  presence  of  new  components  in  the 
search  space  which  offer  and  utilize  services,  and  allow  for  the  selection  of  components 
meeting  the  necessary  functional  as  well  as  non-functional  requirements  (such  as  desired 
levels  of  Quality  of  Service).  The  infrastructure  will  also  need  to  provide  translation 
capabilities  for  specific  models.  The  UniFrame  Resource  Discovery  Service  (URDS) 
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architecture,  proposed  in  this  thesis,  is  designed  to  provide  this  infrastructure  to  support 
universal  dynamic  resource  discovery. 


1.2  Objectives:  Statement  of  Goals 


The  objectives  of  this  thesis  are: 

•  To  bring  about  a  shift  in  paradigms  in  the  field  of  spontaneous  resource  discovery 
from  a  “device”  based  discovery  approach  to  a  “service”  based  discovery  approach. 
Traditionally  the  field  of  dynamic  resource  discovery  has  been  oriented  towards 
spontaneous  discovery  of  “devices”.  This  thesis  aims  to  use  discovery  techniques  to 
detect  “services”  developed  in  diverse  component  models.  The  thesis  also  aims  to 
propose  a  framework  wherein  the  dynamic  resource  discovery  service  will  be  coupled 
with  a  container  for  adapters  to  provide  integration  broker  capabilities. 

•  To  propose  an  architecture  structured  as  a  platform  independent  design  specification 
for  the  URDS.  The  architecture  will  address  the  issues  of  scalability,  adoptability, 
security  and  fault  tolerance  and  aim  to  provide  an  encompassing  view  of  the  end 
service,  computation  and  middle  support  required.  The  architecture  will  provide 
details  of  the  information  specifications,  configurations  of  the  interacting  components 
including  detailed  algorithms  of  the  functions  required  to  support  distributed 
interaction  between  objects  and  an  analysis  of  these  algorithms. 

•  Develop  a  proof-of-concept  prototype  for  the  URDS  and  validate  the  principles 
behind  URDS. 


•  Indicate  the  inter-relations  between  the  URDS  and  other  components  of  UniFrame. 
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1.3  Contributions  of  this  thesis 


The  contributions  of  this  thesis  are: 

•  Provides  a  comprehensive  survey  of  the  existing  resource  discovery  services  detailing 
their  characteristics.  The  survey  outlines  the  purpose  of  existing  resource  discovery 
services  and  establishes  the  need  for  the  development  of  a  resource  discovery  service 
which  is  capable  of  bridging  the  interoperability  gap  that  is  inherent  is  current 
discovery  services. 

•  Proposes  a  novel  approach  to  discovering  services  dynamically  based  on  the  concept 
of  extending  the  native  registries  of  different  component  models  to  be  ‘active’  and 
‘introspective’.  The  architecture  proposed  also  automates  the  process  of  selecting 
components  based  on  their  computational,  cooperational,  auxiliary  attributes  and  QoS 
metrics. 

•  Proposes  a  framework  wherein  the  dynamic  resource  discovery  service  can  be 
coupled  with  a  container  for  adapters  to  provide  integration  broker  capabilities. 

•  Proposes  a  platform  independent  architectural  model  for  the  UniFrame  Resource 
Discovery  Service.  The  following  aspects  of  the  URDS  architectural  model  are 
presented  at  appropriate  levels  of  abstraction: 

o  Information  Aspect  describing  the  scope  and  nature  of  information 
specifications. 

o  Computational  Aspect  describing  the  configurations  of  the  interacting 
computational  objects. 


6 


o  Engineering  Aspect  wherein  the  meehanisms  and  funetions  required  to 
support  distributed  interaetion  between  objeets  is  deseribed. 
o  Technology  Aspect  wherein  a  detailed  description  of  the  components  and  the 
technology  used  to  realize  the  system  is  presented. 


1 .4  Organization  of  this  thesis 

This  thesis  is  organized  into  6  chapters.  The  introduction  of  the  problem  domain, 
problem  statement,  definition  of  goals  and  the  contributions  of  the  thesis  were  presented 
in  this  chapter.  Chapter  2  provides  a  survey  of  the  existing  resource  discovery  services 
and  establishes  the  need  for  a  meta-level  “service”  based  discovery  service.  Chapter  3 
provides  an  overview  of  UA  and  URDS  and  outlines  the  design  concepts  on  which  the 
URDS  architecture  is  based.  Chapter  4  describes  the  URDS  architecture  focusing  on  the 
high-level  design,  and  the  algorithms  and  interactions  of  the  components  that  comprise 
the  architecture.  Chapter  5  describes  a  prototype  implementation  and  its  validation 
through  experimentation.  Finally,  this  thesis  concludes  with  a  discussion  of  the  features 
of  URDS  in  comparison  with  other  resource  discovery  services  in  Chapter  6. 
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2.  BACKGROUND  AND  RELATED  WORK 


This  chapter  provides  a  survey  of  existing  resource  discovery  protoeols  under  the 
categories  of  direetory-based  and  discovery-based  services.  Section  2.1.1  describes 
various  directory  services.  Section  2.1.2  describes  various  diseovery  serviees.  A 
comparison  between  the  features  of  directory-based  and  discovery-based  resource 
discovery  services  is  presented  in  Section  2.1.3. 

2.1  Resource  Discovery  Protocols 

Resource  Discovery  Protoeols  perform  the  task  of  identifying  resourees  on  a 
network  and  making  these  resources  accessible  to  users  and  applieations.  Resources  may 
include  various  services  such  as  web  services,  component  services,  or  devices  sueh  as 
conventional  computers,  hand  held  eomputers  (PDAs),  peripheral  devices  such  as 
printers,  and  speeialized  network  devices  such  as  digital  cameras,  and  telephones.  The 
protocols  for  resource  discovery  are  presented  under  the  following  two  categories: 
o  Lookup  (Directory)  Services  and  Statie  Registries, 
o  Diseovery  Services. 

The  primary  difference  between  ‘discovery’  and  ‘lookup’  services  is  that  a 
discovery  service  usually  supports  lookup,  but  many  ‘lookup’  services  do  not  support 
discovery  [MCGOO].  A  detailed  discussion  of  these  eategories  is  presented  in  the 
following  subsections. 
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2.1.1  Lookup  (Directory)  Services  and  Static  Registries 

Lookup  as  defined  by  McGrath  in  [MCGOO]  refers  to  the  “process  of  locating  a 
specific  object  or  resource  either  by  exact  name  or  address,  or  by  some  matching 
criteria.  Lookup  is  ‘passive  in  that  it  is  initiated  by  a  seeker,  and  requires  the  existence 
of  some  directory  or  other  agent  to  answer  the  request.  Lookup  may  be  done  in  a 
statically  configured  environment;  the  directory  need  not  be  writable”.  Some  examples 
of  lookup  services  include  Universal  Description,  Discovery  and  Integration  (UDDl) 
registry  [UDDOO],  CORBA  Naming  and  Trader  Services  [OMGOO,  OMGOl],  Light 
Weight  Directory  Access  Protocol  (LDAP)  [WAH97],  Domain  Name  Service  (DNS) 
[MOC87],  X.500  [COUOl]  and  GNS  [COUOl].  The  following  subsections  provide  a 
brief  discussion  of  the  above-mentioned  ‘lookup’  services. 

2. 1.1.1  Universal  Description,  Discovery  and  Integration  (UDDI)  Registry 

Universal  Description,  Discovery  and  Integration  (UDDl)  as  defined  in  [UDDOO] 
is  a  “specification  for  distributed  Web-based  information  registries  of  Web  services  i.e., 
UDDl  specifications  define  a  way  to  publish  and  discover  information  about  Web 
services.  ”  The  term  “Web  service”  is  defined  in  [UDDOO]  as  -  “A  Web  Service  describes 
specific  business  functionality  exposed  by  a  company,  usually  through  an  Internet 
connection,  for  the  purpose  of providing  a  way  for  another  company  or  software  program 
to  use  the  service  ”.  Since  UDDl  aims  at  providing  an  open  specification  and  set  of  tools 
for  discovering  Web  Services  on  the  Internet  it  utilizes  the  World  Wide  Web  Consortium 
(W3C)  [W3C]  standard  service  definition  language  -  Web  Services  Description  Language 
(WSDL)  [CHROl].  WSDL  is  an  XML  [BRAOO]  grammar  for  describing  the  capabilities 
and  technical  details  of  Simple  Object  Access  Protocol  (SOAP)  [BOXOO]-based  web 
services.  UDDl  data  is  hosted  by  operator  nodes,  which  are  companies  that  are 
committed  to  running  a  public  node  that  confirms  to  the  specifications  governed  by  the 
uddi.org  consortium.  Three  public  nodes  exist  which  include  Microsoft,  IBM  and  HP 
whose  contents  are  synchronized  regularly. 
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The  components  involved  in  the  UDDI  architecture  are  the  Web  Service 
Providers,  Service  Requesters  and  Service  Brokers  (UDDI  Business  Registries). 

The  fundamental  operations  performed  by  these  components  are: 

•  Service  providers  deploy  and  publish  services  by  registering  them  with  the 
Service  Broker.  The  interaction  with  the  Service  Broker  and  the  registration 
process  is  done  using  the  UDDI  API.  The  UDDI  APIs  are  in  the  form  of  SOAP- 
based  web  services  that  fall  into  two  categories,  namely  inquiry  and  publishing. 
To  invoke  these  APIs  SOAP  message  is  sent  with  the  appropriate  body  content. 

Example:  <lind_business  generic=‘1.0’  xmlns=‘urn:uddi-org:api’> 

<name>XYZ  industries  </name> 

</ fmd_business> 

The  SOAP  response  contains  all  businesses  that  match  criteria  and  registered 
services  for  each  business  in  the  form  of  XML  data  structure. 

•  Service  requestors  find  services  by  searching  the  Service  broker’s  registry  of 
published  services.  Locating  services  is  done  via  a  combination  of  UDDI  and 
Web  Services  Description  Language  (WSDL). 

•  Service  requestors  bind  to  the  Service  provider  and  consume  the  available 
services.  Binding  to  Service  Providers  leverages  information  specified  in  WSDL 
and  the  SOAP  protocol. 


2. 1.1. 2  CORBA  Trader  Services 

The  CORBA  Trader  Service  [OMGOO]  provides  “Yellow  Pages”  for  objects, 
enabling  them  to  publicize/request  services.  The  Trader  Service  facilitates  ‘matchmaking’ 
between  service  providers  {Exporters)  and  service  consumers  {Importers).  The  exporters, 
which  are  CORBA  objects,  use  the  interfaces  provided  by  the  Trader  Services  to  register 
their  services.  The  information  about  the  service  registered  with  the  Trader  comprises  of 
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a  reference  to  the  object  providing  the  service,  information  about  the  operations 
supported  such  as  their  names,  parameters  and  result  types,  and  other  properties 
describing  the  capabilities  of  the  service.  The  Trader  stores  the  type  descriptions  in  a 
repository  and  also  maintains  a  database  of  service  objects.  The  clients  or  importers, 
which  are  CORBA  Objects,  can  query  the  Trader  for  a  list  of  services  registered  with  it  or 
make  a  request  for  a  particular  service  by  specifying  the  service  type  and  properties 
desired  in  the  service.  The  trader  will  find  a  match  for  the  client  based  on  the  search 
criteria.  Traders  can  be  linked  to  form  a  federation  of  traders.  This  linkage  of  traders 
allows  a  trader  to  make  the  offer  spaces  of  other  traders  become  implicitly  available  to  its 
own  clients.  The  Trader  Service  does  not  guarantee  that  the  registered  objects  are 
available.  It  also  does  not  provide  notification  and  security  features  and  needs  to  be 
augmented  with  the  CORBA  event  services  and  security  services  to  provide  these 
features.  The  Trader  Service  is  defined  as  CORBA  interfaces,  and  all  advertisements, 
requests,  and  replies  are  CORBA  objects.  Since  the  Trader  Services  depends  on  CORBA, 
all  participants  must  be  cast  as  CORBA  objects  and  use  CORBA  protocols. 

2. 1 . 1 .3  X.500  and  Lightweight  Directory  Access  Protocol  (LDAP) 

LDAP  (Lightweight  Directory  Access  Protocol)  is  a  software  protocol  for 
enabling  anyone  to  locate  organizations,  individuals,  and  other  resources  such  as  files  and 
devices  in  a  network,  whether  on  the  public  Internet  or  on  a  corporate  intranet.  LDAP  is  a 
"lightweight"  (smaller  amount  of  code)  version  of  Directory  Access  Protocol  (DAP), 
which  is  part  of  X.500  [1TU97],  a  standard  for  directory  services  in  a  network.  The 
directory  service  is  organized  like  a  tree  and  is  referred  to  as  a  Directory  Information 
Tree  (D1T)[W1L99].  The  LDAP  data  format  is  structured  as  a  scalable  hierarchy  of  name 
spaces,  with  an  added  flexibility  to  form  a  relational  grouping  of  entries.  An  entry  in  the 
LDAP  server  is  analogous  to  a  record  in  a  relational  database.  LDAP  is  extensible,  and 
allows  storage  of  different  kinds  of  information.  LDAP’ s  query  model  allows  for  search 
and  retrieval  of  entries  stored  in  the  LDAP  directory  server.  Since  LDAP  is  organized  as 
a  hierarchy,  the  queries  can  be  limited  to  particular  parts  of  the  hierarchy.  Though  the 
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design  is  scalable  queries  over  very  large  domains  are  likely  to  be  very  inefficient.  LDAP 
does  not  have  any  built  in  security  model  and  relies  on  other  network  services  for  this 
purpose.  LDAP  does  not  specify  protocols  for  “spontaneous”  discovery  and  because  of 
the  complexity;  it  may  not  be  well  suited  for  either  near  real-time  discovery,  or  for  very 
large  numbers  of  services  [MCGOO]. 


2. LI. 4  Global  Name  Service  (GNS)  and  Domain  Name  Service  (DNS) 


Global  Name  Service  [COUOl]  is  designed  to  provide  facilities  for  resource 
location,  mail  addressing  and  authentication.  GNS  manages  a  naming  database  that  is 
composed  of  a  tree  of  directories  holding  names  and  values. 

Domain  Name  System  (or  Service),  [MOC87],  is  an  Internet  service  that  translates 
domain  names  into  IP  addresses.  The  DNS  protocol  provides  static  database  of  name- 
address  maps,  which  is  hierarchically  partitioned.  The  naming  data  is  replicated  and 
cached  in  order  to  achieve  scalability.  Recent  extensions  to  DNS  support  a  very  limited 
set  of  service  types  and  a  few  attributes  that  can  be  used  to  search  [GUL96].  The  types  of 
queries  supported  by  DNS  include  host  name  resolution  and  reverse  resolution,  mail  host 
location,  host  information  and  well-known  services  information  [COUOl].  DNS  is  a 
trusted  service,  security  is  provided  by  controlling  access  to  a  few  privileged  users. 
Arbitrary  user  applications  may  not  add  or  modify  the  DNS  database. 


2.1.2  Discovery  Services 

“Discovery”  refers  to  the  spontaneous  process,  in  which  resources  or  services 
‘discover’  other  resources  on  the  network,  and  present  themselves  to  these  other 


resources. 
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Several  protoeols  exist  for  serviee  diseovery,  prominent  among  whieh  are: 
Serviee  Loeation  Protoeol  (SLP)  [GUT99b],  JINl  [SUNOla],  Ninja  Projeet:  Seeure 
Serviee  Diseovery  Serviee  (SSDS)  [CZE99,  N1N02],  Salutation  [SAL,  SAL99a, 
SAL99b],  Bluetooth  [BLU],  Universal  Plug  and  Play  (UPnP)  [CHR99,  UPNP99],  and 
Simple  Serviee  Diseovery  Protoeol  (SSDP)  [GOL99]. 

The  following  seetions  provide  an  overview  of  the  above-mentioned  diseovery 
serviees. 

2, 1.2.1  Serviee  Loeation  Protoeol  (SLP) 

SLP  Version  2  [GUT99a]  is  an  Internet  Engineering  Task  Loree  (IE TP)  standard 
framework  for  resouree  diseovery.  SLP  arehiteeture  eomprises  of  the  following 
eomponents: 

•  User  Agents  (UA):  UAs  perform  serviee  diseovery  on  behalf  of  elients. 

•  Service  Agents  (SA):  SAs  advertise  the  loeation  and  eharaeteristies  of  serviees. 

•  Directory  Agents  (DA):  DAs  aet  as  direetories  whieh  aggregate  serviee 
information  reeeived  from  SAs  in  their  database  and  respond  to  serviee  requests 
from  UAs. 

DAs  ean  be  replieated  or  organized  as  hierarehieal  or  graph  of  domains. 

Diseovery  of  DAs  by  UAs  and  SAs  ean  be  implemented  in  following 
eonfigurations: 

•  Active  Discovery:  SAs  and  UAs  multieast  SLP  requests. 

•  Passive  Discovery:  DAs  announee  their  presenee  by  periodieally  multieasting 
advertisement  messages. 

•  Dynamic  Host  Configuration  Protocol  (DHCP)  Options  for  SLP  [PER99]:  UAs 
and  SAs  ean  loeate  DAs  using  DHCP  wherein  DHCP  servers  eonfigured  with  this 
option  distribute  the  DA  addresses  to  agents  that  require  them. 
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SLP  configuration  allows  the  following  two  modes  of  operation  [GOVOO]; 

•  Without  DAs:  This  requires  no  administration.  UAs  multieast  or  broadeast  serviee 
requests  to  SAs,  whieh  are  listening  on  well-known  ports.  When  a  mateh  is  found 
SAs  respond  to  the  UAs  using  unieast. 

•  With  DAs:  The  protoeol  is  more  effieient,  in  this  eonfiguration.  The  UAs,  SAs  and 
DAs  are  eonfigured  as  members  of  a  seope  and  eommunieation  takes  plaee 
between  them  only  if  they  support  the  same  seope.  UAs  and  SAs  eommunieate 
with  DAs,  whieh  are  listening  on  well-known  ports  using  unieast  messages. 
Serviees  are  advertised  using  a  “Serviee  URL”  [GUT99a]  and  a  “Serviee 

Template”[GUT99e].  The  Serviee  URL  eomprises  of  the  IP  address  of  the  serviee,  the 
port  number,  and  path.  Serviee  Templates  speeify  the  attributes  that  eharaeterize  the 
serviee  and  their  default  values.  Serviee  requests  may  mateh  aeeording  to  serviee  type  or 
by  attributes.  SLP  supports  fairly  powerful  syntax  for  attribute  matehing  based  on 
templates  and  LDAPv3  predieate  [WAH97].  SLP  supports  authentieation,  but  does  not 
speeify  it.  It  does  not  support  eneryption. 


2. 1.2.2  JINI 

JlNl  is  Java  based  framework  for  spontaneous  diseovery  developed  by  Sun 
Mierosystems.  [EDW99]  JINI  arehiteeture  [SUNOla]  is  similar  to  SLP.  However,  JINI  is 
very  tightly  bound  to  the  Java  environment.  Eaeh  JINI  deviee  is  assumed  to  have  a  Java 
Virtual  Maehine  (JVM)  running  on  it.  JINI  uses  Java  Remote  Method  Invoeation  (RMI) 
[RMI]  protoeol  for  eommunieation,  whieh  supports  exehange  of  serialized  Java  objeets. 
The  main  eomponents  of  a  JINI  system  and  their  funetions  are; 

•  Service:  A  serviee  is  a  logieal  eoneept  defined  and  identified  by  a  Java  interfaee. 
The  publiely  visible  part  of  the  serviee,  whieh  is  downloaded  by  the  elients,  is 
referred  to  as  the  “serviee  objeet”  or  “serviee  proxy”.  A  serviee  registers  this 
“serviee  objeet”  or  “serviee  proxy”  with  the  Eookup  serviee. 
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•  Client:  The  client  contacts  the  Lookup  Service  requesting  a  service  and  the 
Lookup  service  returns  it  the  “service  object”  or  “service  proxy”  which  is  copied 
to  the  client’s  JVM  and  any  further  communication  with  the  service  by  the  client 
is  conducted  through  the  proxy.  The  client  request  is  basically  a  simple  template 
for  matching  string  attributes.  However,  the  request  and  the  matching  must  be 
implemented  as  Java  objects,  following  JINI  specified  interfaces. 

•  Lookup  Service  (Service  Locator):  The  Lookup  Service  serves  as  a  directory  of 
available  services.  Lookup  Service  listens  on  a  well-known  port  for  unicast  or 
multicast  messages.  When  Lookup  service  gets  requests  from  services  to  register 
them  or  from  clients  requesting  services,  it  returns  them  a  “registrar”  object, 
which  serves  as  a  proxy  to  the  Lookup  Service  and  runs  on  the  service’s  or 
client’s  JVM.  Any  requests,  which  are  to  be  made  of  the  Lookup  service,  can  be 
made  through  the  proxy  “registrar”. 

The  JINI  Discovery  protocol  is  used  by  JINI  components  (services,  clients,  lookup 
services)  to  locate  other  relevant  JINI  components  in  the  network.  The  discovery  process 
operates  in  the  following  two  modes: 

•  Multicast:  The  discovery  processes,  in  this  mode  are  categorized  as  aggressive, 
lazy  and  peer  lookup.  During  aggressive  discovery  a  JINI  component  transmits 
probes  at  a  fixed  interval  for  a  specified  period,  or  until  it  has  discovered  a 
sufficient  number  of  Lookup  services.  Aggressive  discovery  only  happens  at 
component  initiation  time.  After  completion  of  aggressive  discovery  the 
component  enters  lazy  discovery,  where  it  listens  for  announcements  sent  at 
intervals  by  lookup  services.  During  lazy  discovery  a  lookup  service  both  listens 
for  announcements  by  other  lookup  services  and  sends  its  own  announcements  at 
the  required  intervals.  Peer  Lookup  [GOVOO]  is  mentioned  in  the  JINI 
specification  as  a  technique  used  by  clients  to  discover  services  in  the  absence  of 
a  lookup  service.  Clients  multicast  request  packets  and  they  receive  direct 
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response  from  the  serviees  from  whieh  the  elients  ean  seleet  the  serviees  they  are 
interested  in  and  drop  the  rest. 

•  Directed:  In  this  mode  the  eomponents  use  a  direeted  discovery  process  in  which 
the  components  have  a  list  of  lookup  services  to  discover  with  which  they  try  to 
establish  connection. 

Other  features  of  the  JINI  architecture  include  the  concept  of  Leasing,  Remote 
Event  Notifications  and  Transactions.  Leasing  mandates  that  all  advertisements  and 
registrations  are  valid  only  for  a  specific  period  of  time  thus  forcing  all  clients  and 
services  to  renew  their  leases  periodically.  Leases  ensure  that  JINI  recovers  from  crashed 
entities  as  these  are  automatically  purged  from  the  lookup  services  when  the  lease  expires 
and  periodic  renewal  of  leases  by  entities  rebuilds  the  global  state  in  case  of  a  Lookup 
Server  failure.  Remote  Event  Notifications  allows  an  object  to  transmit  notifications  of 
events  that  have  occurred  within  the  object  to  other  objects,  which  may  have  registered 
their  interest  in  such  events.  JINI  Transactions  provide  for  a  set  of  wrapped  operations 
wherein  an  entire  set  of  operations  succeeds  or  fails  without  scope  for  partial  success. 

Some  of  the  drawbacks  of  the  JINI  architecture  include  a  limited  filtering 
mechanism  as  when  compared  to  other  services  like  LDAP,  SLP,  CORBA  Trader 
Service,  or  other  XML  based  approaches.  JINI  cannot  interoperate  with  any  other 
protocol  or  language  environment.  The  devices  must  either  implement  a  JVM,  or  else  use 
a  proxy.  JINI  security  is  based  on  the  weak  security  provided  by  Java  and  cryptography  is 
not  mandatory. 

2. 1.2. 3  Ninja  Project:  Secure  Service  Discovery  Service  (SSDS) 

The  SSDS  [CZE99,  NIN02]  is  part  of  the  Ninja  research  project  at  University  of 
California,  Berkeley.  The  main  components  of  the  SSDS  system  and  their  function  in  the 
discovery  process  is  as  follows: 
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•  Service  Discovery  Service  (SDS)  Servers:  SDS  Servers  are  organized  into 
hierarchical  domains  (domain  specifies  their  network  extent).  The  servers 
periodically  multicast  authenticated  messages  containing  the  multicast  address  for 
sending  service  announcements.  The  SDS  servers  cache  the  service  descriptions 
that  are  advertised  in  the  domain. 

•  Services:  The  Services  listen  for  SDS  Server  announcements  and  multicast  the 
service  descriptions  to  the  multicast  address  using  authenticated,  encrypted,  one¬ 
way  service  broadcasts. 

•  Clients:  Clients  discover  the  SDS  server  for  their  domain  by  listening  to  a  well- 
known  SDS  global  multicast  address.  A  client  uses  Authenticated  RMI  [CZE99, 
WEL]  to  connect  to  the  SDS  server  and  submits  a  query  in  the  form  of  an  XML 
template. 

•  Certificate  Authority  (CA):  The  SDS  uses  certificates  signed  by  the  CA  to 
authenticate  bindings  between  principals  (components  in  the  SDS  system)  and 
their  public  keys. 

•  Capability  Manager  (CM):  The  SDS  uses  capabilities  as  an  access  control 
mechanism  to  enable  services  to  control  the  set  of  users  that  are  allowed  to 
discover  their  existence.  The  CM  generates  and  distributes  capabilities  to  all  the 
users. 

The  SSDS  shares  similarities  with  other  discovery  protocols,  with  significant 
improvements  in  reliability,  scalability,  and  security.  SSDS  is  implemented  in  Java  and 
uses  Java-RMI  for  remote  calls.  It  uses  XML  for  service  description  and  location. 

The  protocol  is  designed  as  an  exchange  of  XML  “documents”,  and  service  location  is 
implemented  by  matching  of  XML  tags  [CZE99,  HOD99].  SSDS  provides  extremely 
strong  mandatory  security:  all  parties  are  authenticated,  and  all  message  traffic  is 
encrypted.  The  security  features  supported  include:  assurance  of  authenticity  of  discovery 
service,  assurance  of  the  privacy  and  authenticity  of  service  descriptions,  two-way 
authenticated  and  encrypted  remote  method  invocation,  and  capabilities  to  authenticate 
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all  principals.  The  hierarchical  organizations  of  the  SDS  Servers  increases  system 
scalability  and  also  serves  for  failure  detection  and  automatic  restart  of  failed  servers. 

2. 1.2.4  Salutation 


The  Salutation  protocol  [SAL,  SAL99a,  SAL99b]  is  an  open  specification  that 
provides  “spontaneous”  configuration  of  network  devices  and  services.  The  Salutation 
architecture  defines  an  abstract  model  with  three  components:  Client,  Server,  and 
Salutation  Manager  (SLM).  The  Salutation  Manager  manages  all  communication,  and 
bridges  across  different  communication  media  as  needed.  Salutation  defines  its  protocol 
based  on  SunRPC.  Salutation  defines  a  specific  (extensible)  record  format  for  describing 
and  locating  services.  This  format  includes  service  type  (such  as  ‘  [PRINT]’)  and 
attributes  (such  as  ‘  color’).  Services  advertise  by  registering  with  one  or  more  Salutation 
Managers.  Clients  locate  services  by  sending  service  requests. 


2. 1.2. 5  Universal  Plug  and  Play  (UPnP)  and  Simple  Service  Discovery  Protocol  (SSDP) 

UPnP  [CHR99,  UPNP99]  is  a  Microsoft  standard  for  spontaneous  configuration. 
UPnP  handles  network  address  resolution,  and  coupled  with  the  IETF  proposal  Simple 
Service  Discovery  Protocol  [GOL99],  it  provides  higher- level  service  discovery.  UPnP 
has  a  similar  architecture  to  Salutation  and  SLP,  and  was  influenced  by  them.  UpnP  uses 
XML  for  device/service  description  and  queries,  which  brings  it  into  the  mainstream  of 
the  evolving  WWW.  At  the  base,  UPnP  provides  “simple  discovery”,  in  which  network 
addresses  are  discovered.  Advertisement  is  done  by  a  local  broadcast  announcement. 
When  successful,  “simple  discovery”  returns  an  IP  address  or  URL  plus  a  “device  type”. 
Services  are  described  by  extended  URLs,  similar  to  (but  completely  incompatible  with) 
SLP.  The  URL  is  for  an  XML  file  with  an  elaborate  description  of  the  device.  Starting 
with  this  URL,  the  SSDP  defines  a  Web  based  discovery  protocol,  which  uses  HTTP 
(with  extensions). 
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2, 1.2.6  Bluetooth  Service  Discovery  Protocol 

Bluetooth  [BLU]  is  a  new  short-range  wireless  transmission  protoeol.  The  Bluetooth 
protoeol  staek  contains  the  Service  Discovery  Protocol  (SDP),  which  is  used  to  locate 
services  provided  by  a  Bluetooth  device.  It  is  based  on  the  Piano  platform  by  Motorola 
and  has  been  modified  to  suit  the  dynamic  nature  of  ad  hoc  communications. 

2.1.3  Features  of  Resource  Discovery  Protocols 

The  underlying  problem  that  all  the  resource  discovery  protocols  are  aiming  solve 
and  the  solutions  to  achieve  the  same  can  be  broadly  summarized  as: 

•  Service  Advertisement:  Service  Providers  advertise  their  services  by  providing 
their  address  and  other  necessary  information.  This  advertisement  could  be 
facilitated  either  by  registration  with  a  directory  service  or  through  multicast  or 
broadcast  communication. 

•  Service  Request:  Service  Consumers  seeking  services  forward  their  request  to 
some  centralized  directory  service  or  make  known  their  request  to  the  world  again 
through  the  process  of  multicast  or  broadcast  communication. 

•  Match  Making:  The  process  in  which  service  producers  and  consumers  hook  up. 
This  could  again  be  facilitated  through  a  directory  service  serving  as  the 
intermediary  or  a  direct  discovery  between  producers  and  consumers.  In  the  case 
where  the  directory  service  serves  as  the  intermediary.  The  discovery  of  the 
service  providers  could  again  be  spontaneous  or  through  the  registration  process. 

Issues  such  as  reliability  and  scalability  are  handled  either  through  a  hierarchical 
or  federated  organization.  A  comparison  of  the  features  of  the  Directory  and  Discovery 
services  is  provided  in  the  table  2.1  compiled  based  on  the  characteristics  summarization 
in  [MCGOO]. 
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Feature  List 

Directory  Services 

Discovery  Services 

Information  Storage  and 

Retrieval 

Storage  of  information  in 

static  databases,  which  can 

be  replicated  for  greater 

scalability. 

Spontaneous  discovery  and 

configuration  of  network 

services  and  devices.  Some 

Discovery  services  like 

SSDS,  JINI  cache  the 

service  information  in 

which  case  they 

periodically  update  the 

cache  to  reflect  the  global 

state  of  the  system. 

Failure  Deteetion 

Do  not  monitor  the 

resources  for  availability  or 

failure  due  to  external 

circumstances  such  and 

node/link  failure,  etc.  They 

usually  do  not  possess  any 

event  generation 

mechanisms  either  to 

inform  clients  of  resource 

registration  or  withdrawal. 

Automatically  configure 

according  to  service 

availability. 

Management 

Centralized  control.  Usually 

maintained  by  privileged 

administrators. 

Decentralized  management 

with  limited  administration. 

Search  Semantics 

Usually  provide  lower 

flexibility  with  respect  the 

search  criteria  that  can  be 

specified. 

Allows  for  selection  of  very 

specific  types  of  service. 

Interoperability 

No  interoperability  between 

different  models  or  services. 

Some  services  offer 

interoperability  through  the 
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use  of  bridges  and  proxies. 

Table  2.1.  Comparison  of  the  Features  of  the  Directory  and  Discovery  services 

The  Directory  and  Discovery  Services  described  this  chapter  are  mostly  designed 
for  ‘closed’  systems,  i.e.,  systems,  although  distributed  in  nature,  are  developed  and 
deployed  in  a  confined  setup.  Such  systems  do  not  take  advantage  of  the  heterogeneity, 
local  autonomy  and  the  open  architecture  that  are  characteristic  of  DCS.  The  URDS 
architecture  on  the  other  hand  is  designed  for  ‘open’  systems  by  providing  for  the 
discovery  and  interoperation  of  distributed  heterogeneous  software  components.  These 
systems  can  be  extended  as  new  needs  surface. 

Chapter  3  provides  an  overview  of  the  UniFrame  Approach  and  the  UniFrame 
Resource  Discovery  Service. 
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3.  OVERVIEW  OE  UNIERAME  APPROACH  (UA)  AND  UNIFRAME  RESOURCE 

DISCOVERY  SERVICE  (URDS) 


Chapter  2  provided  descriptions  of  various  resource  discovery  services  under  the 
categories  of  directory  and  discovery  services.  This  chapter  provides  an  overview  of  the 
UniErame  Approach  (UA)  and  how  it  can  be  used  for  developing  DCS.  The  chapter  also 
presents  a  brief  discussion  of  the  UniErame  Resource  Discovery  Service  (URDS) 
architecture  outlining  the  design  concepts  on  which  the  architecture  is  based.  The  detailed 
description  of  the  URDS  architecture  is  presented  in  Chapter  4. 


3.1  UniErame  Approach  (UA)  and  UniErame  Resource  Discovery  Service  (URDS) 

The  UniErame  Approach  (UA)  aims  at  facilitating  an  automatic  or  semi-automatic 
creation  of  a  DCS  based  on  an  integration  of  heterogeneous  components.  The  UA 
specifies  a  framework  for  component  developers  to  create,  test  and  verify  from  the  point 
of  view  of  QoS,  the  components  they  develop  and  deploy  on  the  network  and  for 
component  assemblers/system  integrators  to  select  and  semi-automatically  generate  a 
software  solution  for  the  DCS  under  consideration. 

As  indicated  in  Chapter  1 ,  the  Unified  Meta-Component  Model  (UMM)  proposed 
in  [RAJOO]  is  the  central  part  of  the  UniErame  Approach.  The  following  subsections 
describe  this  meta-model. 
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3.2  Unified  Meta-Component  Model  (UMM) 

UMM  consists  of  three  entities:  a)  Components,  b)  Services  and  Serviee 
Guarantees,  and  e)  Infrastructure.  URDS  represents  the  infrastructural  part  of  the  UMM. 


3.2.1  Components 

Components  in  UniFrame  are  autonomous  entities,  whose  implementations  are 
non-uniform,  i.e.,  each  component  adheres  to  some  distributed-eomponent  model  but 
there  is  no  notion  of  a  unified  implementational  framework.  Eaeh  component  has  a  state, 
an  identity,  a  behavior,  well-defined  interfaees  and  a  private  implementation.  In  addition, 
eaeh  component  in  UMM  has  three  aspects: 

•  Computational  Aspect:  The  eomputational  aspect  reflects  the  task(s)  carried  out 
by  each  component.  It  in  turn  depends  upon:  a)  the  objective(s)  of  the  task,  b)  the 
techniques  used  to  aehieve  these  objectives,  and  c)  the  precise  specification  of  the 
funetionality  offered  by  the  eomponent.  The  computational  aspect  of  a  component 
is  described  by  its  inherent  attributes  (book-keeping  aspects,  e.g.,  author,  version, 
ete.)  and  functional  attributes  (formal  aspects,  i.e.,  computation,  contracts  and 
levels  of  serviee). 

•  Cooperative  Aspect:  The  cooperative  aspect  of  a  component  indicates  its 
interaetion  with  other  components.  Informally,  the  cooperative  aspeet  of  a 
component  may  eontain:  i)  Expected  collaborators  -  other  components  that  can 
potentially  eooperate  with  this  eomponent,  ii)  Pre-processing  collaborators  - 
other  eomponents  on  whieh  this  component  depends  upon,  and  iii)  Post¬ 
processing  collaborators  -  other  components  that  may  depend  on  this  component. 
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Auxiliary  Aspect:  In  addition  to  computation  and  cooperation,  mobility,  security, 
and  fault  tolerance  are  neeessary  features  of  a  DCS.  The  auxiliary  aspeet  of  a 
eomponent  addresses  these  features. 


3.2.2  Services  and  Serviee  Guarantees 

Serviees  in  UniFrame  eould  be  a  eomputational  effort  or  an  aeeess  to  underlying 
resourees.  In  DCS,  it  is  natural  to  have  several  ehoiees  for  obtaining  a  speeifie  serviee. 
Thus,  eaeh  eomponent,  in  addition  to  indieating  its  funetionality,  must  be  able  to  speeify 
the  quality  of  the  serviee  offered. 

The  Quality  of  Serviee  (QoS)  is  an  indieation  given  by  a  software  eomponent 
about  its  eonfidenee  to  earry  out  the  required  serviees  in  spite  of  its  eonstantly  ehanging 
exeeution  environment  and  a  possibility  of  partial  failures.  The  QoS  offered  by  eaeh 
eomponent  is  dependent  upon  the  eomputation  performed,  algorithm  used,  expeeted 
eomputational  effort  and  resourees  required,  the  eost  of  eaeh  serviee,  and  the  dynamies  of 
supply  and  demand.  The  task  of  guaranteeing  the  neeessary  QoS  is  a  key  issue  in  any 
quality-oriented  framework.  The  UA  to  assuring  the  QoS  of  a  DCS  is  made  up  of  three 
steps:  a)  the  creation  of  a  catalog  of  QoS  parameters  (or  metrics),  b)  a  formal 
specification  of  these  parameters,  and  c)  a  mechanism  for  ensuring  these  parameters,  both 
at  eaeh  individual  eomponent  level  and  at  the  entire  system  level.  In  [RAJ02,  BRA02], 
these  three  steps  are  deseribed  in  detail. 


3.2.3  Infrastrueture 

URDS  is  designed  to  provide  the  infrastrueture  neeessary  for  diseovering  and 
assembling  a  eolleetion  of  eomponents  for  building  a  DCS. 
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The  URDS  infrastructure  (illustrated  in  Figure  3.1)  comprises  of  the  following 
components:  i)  Internet  Component  Broker  (ICB)  which  is  a  collection  of  the  following 
services  -  Query  Manager  (QM),  the  Domain  Security  Manager  (DSM),  Link  Manager 
(LM)  and  Adapter  Manager  (AM)  ii)  Headhunters  (HHs),  iii)  Meta-Repositories,  iv) 
Active-Registries,  v)  Services  (SL.Sn),  and  vi)  Adapter  Components  (ACL.ACn).  Figure 
3.1  also  illustrates  the  users  (CL.Cn)  of  the  URDS  system  who  can  be  the  Component 
Assemblers,  System  developers  or  System  Integrators.  Section  3.5  provides  a  brief 
overview  of  each  of  these  components.  The  numbers  in  the  Figure  3.1  indicate  the  flow 
of  activities  in  the  URDS.  These  are  explained,  in  detail,  in  the  context  of  an  example  in 
section  3.5.1. 


Figure  3.1.  URDS  Architecture 
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3.3  Specification  of  Components  in  UniFrame 

UniFrame  specifications  are  initially  informally  indicated  in  a  natural  language¬ 
like  style.  This  natural-language  style  specification  indicating  the  computational, 
cooperative,  auxiliary  attributes  and  QoS  metrics  of  the  component  is  refined  into  a  more 
standard  XML-based  specification  during  the  Component  Development  and  Deployment 
Phase  as  described  in  Section  3.6.1.  XML  [BRAOO]  is  selected  as  the  standard  for  service 
specification  since  it  is  general  enough  to  express  the  required  concepts,  it  is  rigorously 
specified,  and  it  is  universally  accepted  and  deployed. 

The  XML-based  UniFrame  Service  Specification,  which  represents  the 
information  needed  to  describe  a  service,  is  comprised  of: 

•  ID  (or  Service  Type  Name):  A  unique  identifier,  comprising  of  the  host  name  on 
which  the  component  is  running  and  the  name  with  which  this  component  binds 
itself  to  a  registry  will  identify  each  service. 

Example:  intrepid.cs.iupui.edu/AccountServerl 

•  Component  Name:  The  name,  with  which  the  service  component  identifies  itself, 
i.e.,  the  class  name  of  the  implementation,  which  is  instantiated  at  the  time  of 
binding.  This  can  be  different  from  the  name  with  which  the  component  binds 
itself  to  a  registry. 

Example:  AccountServer 

•  Description:  A  brief  description  of  this  service  component. 

Example:  Provides  an  account  management  system. 

•  Function  Descriptions:  A  brief  description  of  each  of  the  functions  supported  by 
the  service  component. 

Example:  javaDeposit,  javaWithdraw,  javaBalance 

•  Syntactic  Contracts:  A  definition  of  the  computational  signature  of  the  service 
interface. 

Example:  void  javaDeposit(fioat  ip),  void  javaWithdrawQ  throws 

OverDrawException,  float  javaBalanccQ. 
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•  Purpose:  Overall  function  of  the  service  component. 

Exampe:  Acts  as  an  Account  Server. 

•  Algorithm:  The  algorithms  implemented  by  this  component. 

Example:  Simple  Addition/Subtraction 

•  Complexity:  The  overall  order  of  complexity  of  the  algorithms  implemented  by 
this  component.  Example:  0(1) 

•  Technology:  The  technology  used  to  implement  this  component. 

Example:  CORBA,  Java  RMI,  etc. 

•  QoS  Metrics:  Zero  or  more  Quality  Of  Service  (QoS)  types.  A  QoS  type  name 
defines  the  QoS  value.  Associated  with  a  QoS  type  is  the  triplet  of  <QoS-type- 
name,  measure,  value>  where  QoS-type-name  specifies  the  QoS  metric,  for 
example,  throughput,  capacity,  end-to-end  delay,  etc.  Measure  indicates  the 
quantification  parameter  for  this  type-name  like  methods  completed/sec,  number 
of  concurrent  requests  handled,  time,  etc.  Value  indicates  a 
numeric/string/boolean  value  for  this  parameter. 

Example:  <Availability,%,90>.  A  catalog  of  Quality  of  Service  parameters  and 
their  metrics  to  be  used  in  ElniErame  specifications  are  indicated  in  [BRA02]. 


Accou.rt'tSet^vecr 

Informal  Description;  I>rovi<les  an  account  management  service. 
Supports  functions  javaDepo  sit(),  j  ava'N^/’i  their  aw  ([),  javaB  alanc  eO- 

1.  O  ompii.t:at:ioi\al  A.t:trd.l>u.t:es: 

a.  1  i<d:  intrepid,  cs.iupui.  e<du/ Ac  count  Server 

2.  : 

b>.  1  A-Cts  as  an  account  server 

t».2  Algorithm;  simple  addition/ subtraction 

t>.3  Compleshty;  0(^1) 

b. 4  S5mtactic  Contracts: 

void  javaDepo  sit(flo  at  ip); 

void  java'VTithdraw^ (float  ip)  throws  overDrawException; 
fl  o  at  j  a  V  aE  al  an  c  e  Q  ; 
b.5  Technology;  Java-RlS/EI 

2.  Cooperation  A.ttx'iljutes: 

2.1)  P*re -pro  cessing  Collaborators:  Accountdient 

3.  Au3ciliary  Attributes:  ISTone 

4.  QoS  IVIetrics: 

Availability;  90“?^ 

End-to -End  Delay:  less  than  10ms 


Eigure  3.2.  Example  of  Informal  Natural  Eanguage-based  Elniframe  Specification 
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Figure  3.2  illustrates  an  example  of  an  informal  natural  language-like  style 
UniFrame  specification.  This  example  is  for  a  Java-RMI  based  bank  account 
management  system  with  services  for  deposit,  withdraw,  and  check  balance. 


The  informal  natural  language-like  specification  in  Figure  3.2  is  translated  into  an 
XML-based  UniFrame  specification  illustrated  in  Figure  3.3. 


<X^OTnponeniNam^'>  AccountServer 

Provides  an  Account  Management  System  </Desanpdon> 

<jF^ urtcdonL}^scripdon  > 

<^M«d:ii<?«>javaDepo sit  unctions 
<^««c’i5f<3«5^ava'Withdraw  </Funcdon> 

<^««^i^o«>javaBalance  </Funciion> 
urtcdottl^scripdon^ 

^Coff^uUtdonalAttributes'> 

<JnherentAitnbutes^ 

<ID >  intrepi d.  cs . iupui .  e du/ Ac c ou nt Serv er  </T £)> 

</Tnh^rvntAttnAut^s>^ 

<F uncdonalAttributes^ 

<Futpos^'>>  Acts  as  Account  Server  </Purpose>^ 

Simple  Addition/Subtraction  </Algonihm> 

<^CoTf^lexity'>  0(1)  </^Oomplexid^> 

'^yntacdcContract^ 

void  javaDeposit(float  ip)  ‘</Contract> 

^Contmct>‘ 

void  java'With draw  throws  OverDrawException 
^^/Contjnct>> 

float  javaEalance()  <^/Contncict^ 

<:ySyntax:ticContrcu:t>' 

Java-RMI  </Fechnology> 

<^/F unctiona2J\iiributes^ 

^^^/CoffiputationaLAttributes^ 

<CooperadngAiinbutes^ 

'^Preproc^ssingCoU^iboraiors'^  AccountClient  <^/PreprocessingCotUiborators^ 
'^^/Coop^ratingA.ttfibutes'>^ 

<  Aujdllar  yAttr  ib  ut  es> 

<bdobilify>^'i^o  ability 
</AuxillaryAttrib  utes> 

^QOSbf etHcs^ 

measure=***Vo**>  90  </^vailabili^>^ 

<^n.d2Et%d.r}^iay  measure="ms"  >10  '^^/End2Kn.dI^^l£^^ 

</QClSAIetr%cs> 

^‘TJniF fnme^ 


Figure  3.3.  Example  of  translated  XML-based  UniFrame  Specification 
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Various  aspects  in  the  service  specification  can  be  identified  through  the  nodes  in  the 
XML  specification.  Nodes  can  be  single  valued  or  multi-valued  in  which  case  they  can 
hold  multiple  child  nodes.  For  example;  the  node  ComponentName  which  introduces  the 
name  of  the  service  component  is  a  single  valued  node,  whereas  the  node 
FunctionDescription  which  introduces  the  names  of  the  functions  supported  by  the 
service  component  has  multiple  child  nodes  each  named  Function. 


3.4  Query  and  Description  of  Target  Code  Architecture 

The  UniFrame  approach  allows  the  system  developers/components 
assemblers/system  integrators  to  present  a  query  to  the  system  in  natural  language-like 
style.  This  query  is  passed  through  a  language  query  processor,  which  extracts  the  key 
words,  constraints,  and  preferences  from  the  query  and  applies  a  knowledge  base  of  the 
domain  maintained  with  it,  to  the  query  to  construct  an  XML-based  query.  The  XML- 
based  query  is  further  processed  into  a  structured  query  language  (SQL)  statement  during 
the  process  of  matchmaking. 

The  general  form  of  a  query  is  a  request  to  create  a  system  that  has  certain  QoS 
parameters.  The  name  of  the  system  is  important  in  identifying  the  application  domain 
and  the  QoS  parameters  help  identify  desired  properties  of  the  system.  A  sample  query 
can  be  stated  informally  as:  Create  an  account  management  system  that  has 
availability>  50%  and  end-to-end  delay  <  50ms  with  preference  maximum  availability. 
(The  preference  can  be  specified  to  indicate  that  if  there  are  multiple  solutions  satisfying 
the  requirements,  then  the  search  results  returned  to  the  developer  need  to  be  sorted  in  the 
order  of  greatest  availability).  The  natural  language-ltke  query  is  processed  into  an  XML- 
based  query  as  depicted  in  Figure  3.4 
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<Query> 

<Descnpiion>  Account  System  </Descripdon> 

<Z)omai«>  Financial  </Domam> 

<End2EndDelay  constraint="<">50  </End2EndDelay> 

<AvailahUky  constraint  =  "  >"  preference  ="max">  50  </Avaikd}ilify> 

</Queiy> 

Figure  3.4.  Example  of  a  Proeessed  XML-based  Query 

During  matehmaking  the  above  XML  based  query  is  further  translated  into  the 
following  structured  query  language  (SQL)  statement:  SELECT  *  LROM 
componentTable  A,  functionTable  B  WHERE  (A.ID  =  B.ID)  AND  {{description  LIKE 
%account%)  OR  {description  LIKE  %system%))  AND  {end2endDelay  <  50)  AND 
{availability  >50). 

The  above  SQL  statement  is  specific  to  the  implementation.  The  URDS 
architecture  proposes  that  the  UniErame  specification  be  stored  in  a  database  (Meta- 
Repository)  so  that  the  natural  language-like  query  can  be  translated  into  a  structured 
query  language  statement  and  executed  against  the  tables  of  the  database  to  find  a  match 
for  the  query.  In  the  sample  SQL  statement  shown  the  terms  componentTable, 
functionTable  refer  to  the  database  tables  in  which  the  parsed  UniErame  specification  is 
stored.  The  componentTable  maintains  the  details  associated  with  the  component  name, 
description,  computational,  cooperating,  auxiliary  attributes,  and  QoS  metrics.  The 
functionTable  holds  details  associated  with  function  names  and  their  associated  syntactic 
contracts.  The  terms  description,  cndlendDelay  and  availability  correspond  to  the 
column  names  of  the  componentTable.  The  implementation  specific  details  of  terms  are 
explained  in  subsection  5. 2. 4. 1.1. 3  of  chapter  5. 


3.5  Overview  of  the  URDS  Architecture 


The  URDS  architecture  is  organized  as  a  federated  hierarchy  in  order  to  achieve 
scalability.  Eigure  3.5  illustrates  this  hierarchical  organization.  Every  ICB  has  a  one  level 
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hierarchy  of  zero  or  more  Headhunters  attached  to  it.  The  ICBs  in  turn  are  linked  together 
with  unidirectional  links  to  form  a  directed  graph.  The  URDS  discovery  process  is 
“administratively  scoped”,  i.e.,  it  locates  services  within  an  administratively  defined 
logical  domain.  "Domain’  in  UniFrame  refers  to  industry  specific  markets  such  as 
Financial  Services,  Health  Care  Services,  Manufacturing  Services,  etc.  The  domains 
supported  are  determined  by  the  organizations  providing  the  URDS  service. 
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Figure  3.5.  Federated  Hierarchical  Organization  of  ICBs 


The  URDS  discovery  protocol  is  based  on  periodic  multicast  announcements.  The 
multicast  communication  is  subject  to  various  security  threats,  such  as  eavesdropping, 
uncontrolled  group  access  and  masquerading.  URDS  addresses  the  security  threats  faced 
in  the  scenario  of  a  discovery  process.  The  security  model  of  URDS  provides  for 
authentication  of  the  principals  involved,  an  access  control  to  multicast  address  resources, 
and  an  encryption  of  the  data  transmitted.  The  model  does  not  at  this  stage  provide  for 
elaborate  protocols  for  establishing  keys,  passwords,  etc.  These  are  considered  as  future 
enhancements  and  are  mentioned  in  Chapter  6. 
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The  URDS  architecture  is  designed  to  handle  failures  through  periodic 
announcements  (in  case  of  Headhunters),  ‘heartbeat’  probes  (in  case  of  Link  Managers) 
and  information  caching.  A  lack  of  communication  from  the  recipients  of  the 
communication  beyond  a  designated  time  range  is  deemed  as  a  failure  of  that  component 
and  the  state  of  the  system  is  accordingly  reset.  The  caches  of  the  Headhunter  and  Link 
Manager  are  updated  based  on  the  responses  received  from  ActiveRegistries  and  Link 
Managers  in  other  ICBs  respectively  or  purged  based  on  lack  of  them. 

Table  3.1  gives  a  brief  description  of  each  of  the  components  that  comprises  the 
URDS  architecture.  The  elaborate  details  are  provided  in  the  next  chapter. 


Internet 

Component 

Broker 

(ICB) 

The  ICB  acts  as  an  all-pervasive  component  broker  in  an  interconnected 

environment.  It  encompasses  the  communication  infrastructure 

necessary  to  identify  and  locate  services,  enforce  domain  security  and 

handle  mediation  between  heterogeneous  components.  The  ICB  is  not  a 

single  component,  but  a  collection  of  services  comprising  of  the  Query 

Manager  (QM),  the  Domain  Security  Manager  (DSM),  Adapter 

Manager  (AM),  and  the  Link  Manager  (LM).  These  services  are 

reachable  at  well-known  addresses.  It  is  envisioned  that  there  will  be  a 

fixed  number  of  ICBs  deployed  at  well-known  locations  hosted  by 

corporations  or  organizations  supporting  this  initiative. 

Domain 

Security 

Manager 

(DSM) 

The  DSM  serves  as  an  authorized  third  party  that  handles  the  secret  key 

generation  and  distribution  and  enforces  group  memberships  and  access 

controls  to  multicast  resources  through  authentication  and  use  of  access 

control  lists  (ACL).  DSM  has  an  associated  repository  (database)  of 

valid  users,  passwords,  multicast  address  resources  and  domains. 

Query 

Manager 

(QM) 

The  purpose  of  the  QM  is  to  translate  a  system  integrator’s  natural 

language-like  query  into  a  structured  query  language  statement  and 

dispatch  this  query  to  the  ‘appropriate’  Headhunters,  which  return  the 
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list  of  service  provider  components  matching  these  search  criteria 

expressed  in  the  query.  ‘Appropriate’  is  determined  by  the  domain  of 

the  query.  Requests  for  service  components  belonging  to  a  specific 

domain  will  be  dispatched  to  Headhunters  belonging  to  that  domain. 

The  QM,  in  conjunction  with  the  LM,  is  also  responsible  for 

propagating  the  queries  to  other  linked  ICBs. 

Link 

Manager 

(LM) 

The  LM  serves  to  establish  links  with  other  ICBs  for  the  purpose  of 

federation  and  to  propagate  queries  received  from  the  QM  to  the  linked 

ICBs.  The  LM  is  configured  by  an  ICB  administrator  with  the  location 

information  of  LMs  of  other  ICBs  with  which  links  are  to  be 

established. 

Adapter 

Manager 

(AM) 

The  AM  serves  as  a  registry/lookup  service  for  clients  seeking  adapter 

components.  The  adapter  components  register  with  the  AM  and  while 

doing  so  they  indicate  their  specialization,  i.e.,  which  component 

models  they  can  bridge  efficiently.  Clients  contact  the  AM  to  search  for 

adapter  components  matching  their  needs. 

Headhunter 

(HH) 

The  Headhunters  perform  the  following  tasks:  a)  Service  Discovery: 

detect  the  presence  of  service  providers  (Exporters),  b)  register  the 

functionality  of  these  service  providers,  and  c)  return  a  list  of  service 

providers  to  the  ICB  that  matches  the  requirements  of  the  component 

assemblers/system  integrators  requests  forwarded  by  the  QM.  The 

service  discovery  process  performs  the  search  based  on  multicasting. 

Meta- 

Repository 

(MR) 

The  Meta-Repository  is  a  data  store  that  serves  a  Headhunter  to  hold  the 

UniFrame  specification  information  of  exporters  adhering  to  different 

models.  The  repository  is  implemented  as  a  standard  relational  database. 

Active 

Registry 

(AR) 

The  native  registries/lookup  services  of  various  component  models 

(RMI,  CORBA,  Voyager)  are  extended  to  be  able  to  listen  and  respond 

to  multicast  messages  from  the  Headhunters  and  also  have  introspection 

capabilities  to  discover  not  only  the  instances,  but  also  the  specifications 

of  the  components  registered  with  them. 
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Sl..Sn 

Services  implemented  in  different  component  models  (RMI,  CORBA, 

etc.,)  identified  by  the  service  type  name  and  the  component’s  informal 

UniFrame  specification  which  is  an  XML  specification  outlining  the 

computational,  functional,  cooperational  and  auxiliary  attributes  of  the 

component  and  zero  or  more  QoS  metrics  for  the  component. 

ACl..ACn 

Adapter  components,  which  serve  as  bridges  between  components 

implemented  in  diverse  models. 

CL.Cn 

Component  Assemblers,  System  Integrators,  System  Developers 

searching  for  services  matching  certain  functional  and  non-functional 

requirements. 

Table  3.1.  Description  of  URDS  components 


3.5.1  Interaction  of  URDS  Components 


Table  3.2,  outlines  the  interactions  between  the  URDS  components  in  servicing  a 
query  for  assembling  an  account  management  system.  This  example  assumes  the 
presence  of  a  pair  of  Java  RMI  server  and  Java  RMI  client  programs,  and  a  pair  of 
CORBA  server  and  CORBA  client  programs,  which  are  available  to  construct  the 
account  management  system.  The  rows  of  the  table  are  numbered  corresponding  to  the 
flow  of  control  shown  in  Figure  3.1.  The  result  of  this  interaction  will  be  an  ensemble  of 
components,  which  may  be  assembled  into  a  complete  system  as  described  in  Section 


3.6.2. 


1 


This  indicates  the  interactions  between  the  principals  (Headhunters/ Active 
Registries)  and  the  DSM. 

The  principals  contact  the  DSM  with  their  authentication  credentials  in  order  to 
obtain  the  secret  key  and  the  multicast  address  for  the  group  communication  (many 
to  one  interaction). 

Example  credentials: 

<name=“Headhunterl”,password=“xxxxx”,domam=“linancial”> 
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<name=“registry2”,password=“yyyyy”,  domain=“financial”> 

The  DSM  authenticates  the  principals  and  returns  a  secret  key  and  multicast 

address  to  a  valid  principal  (one  to  many  interaction). 

Example  response: 

<secretkey  =  keyforFinancialDomain,  multicast  address=“224.2.2.2”> 

2 

This  indicates  the  interactions  between  Service  Exporter  Components  and  active 

registries. 

The  service  exporter  components  register  with  their  respective  registries  (many  to 

one  interaction). 

Example:  <id=“intrepid.cs. iupui.edu/AccountServer”> 

These  registries  in  turn  query  these  components  for  their  UniFrame  Specification 

(one  to  many  interaction). 

Example:  <introspect  property  =  “UniFrameSpecURL”> 

The  components  respond  with  the  URL  at  which  the  specification  is  located  (many 

to  one  interaction). 

Example:  <url=“C:\Account  System\AccountServerSpec.xml”> 

3 

This  indicates  the  interactions  between  Headhunters  and  Active  Registries. 

Headhunters  periodically  multicast  their  presence  to  multicast  group  addresses  (one 

to  many  interaction). 

Example  message:  <Headhunterlocation=phoenix.cs. iupui.edu/Headhunterl> 

Active  Registries,  which  are  listening  for  the  multicast  messages  from  the 

Headhunters  at  this  group  address,  respond  to  Headhunter’s  multicast  messages  by 

passing  their  contact  information  to  the  Headhunter  (many  to  many  interaction). 

Example:  <registrylocation=magellan.cs. iupui.edu/registry2> 

Headhunters  query  the  active  registries,  which  respond  to  their  announcements,  for 

the  UniFrame  specification  information  of  all  the  components  registered  with  them 

(one  to  many  interaction). 

The  active  registries  respond  by  passing  to  the  Headhunter  the  list  of  components 

registered  with  them  and  the  detailed  UniFrame  specification  of  these  components 

(many  to  many  interaction). 
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4  This  indicates  the  interaetions  between  a  Headhunter  and  a  Meta-Repository. 
Headhunters  store  the  eomponent  information  obtained  from  the  aetive  registries 
onto  the  Meta-Repository  (one  to  one  interaction). 

Headhunters  query  the  Meta-Repository  to  retrieve  eomponent  information  (one  to 
one  interaetion). 

Example: 

<SQL  statement  =  “SELECT  *  EROM  componentTable  K,functionTable  B 
WHERE  (A.ID  =  B.ID)  AND  {{description  LIKE  %aeeount%)  OR  {description 
LIKE  %system%))  AND  {end2endDelay  <  50)  AND  {availability  >  50)”> 
Meta-Repository  returns  seareh  results  to  Headhunter  (one  to  one  interaetion). 

5  This  indieates  the  interaetions  between  the  QM  and  Component 
Assemblers/System  Integrators. 

System  Integrators  eontaet  the  QM  and  speeify  the  funetional  and  non-funetional 
seareh  eriteria.  The  System  Integrators  ean  optionally  speeify  the  domain  for  their 
query  or  allow  the  natural  language  proeessor  of  the  QM  to  determine  the  domain 
of  the  query,  (many  to  one  interaetion). 

Example:  The  natural  language-like  system  integrator  query  is  as  follows: 

<NL  Query=  “Create  an  account  management  system  that  has  end-to-end  delay  < 
50  ms  and  availability>  50%  with  preference  maximum  availability.  ”>. 

The  QM  returns  the  seareh  results  to  the  elients  (one  to  many  interaetion). 

Eigure  3.6  depiets  an  example  of  the  seareh  results  returned  to  the  system 
integrator. 


Eigure  3.6.  Example  of  Seareh  Results. 
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6 

This  indicates  the  interaction  between  the  QM  and  DSM. 

QM  contacts  DSM  for  contact  information  of  registered  Headhunters  belonging  to 

the  domain  of  client  query  (one  to  one  interaction). 

DSM  responds  with  the  list  of  registered  Headhunters  (one  to  one  interaction). 

Example; 

<  phoenix.cs.iupui.edu/Headhunterl ,  magellan.es. iupui.edu/Headhunter2> 

7 

This  indicates  the  interactions  between  the  QM  and  Headhunters. 

The  QM  propagates  the  System  Integrator’s  query  to  all  registered  Headhunters, 

which  fall  in  the  domain  of  the  System  Integrator’s  search  request  (one  to  many 

interaction). 

The  Headhunters  respond  to  the  QM  query  with  search  results  matching  the  criteria 

(many  to  one  interaction). 

8 

This  indicates  the  interactions  between  adapter  components  and  AM. 

Adapter  components  register  with  the  AM,  which  is  running  at  a  well-known 

location  (many  to  one  interaction). 

9 

This  shows  the  interactions  between  the  clients  and  the  AM. 

Clients  contact  the  AM  at  the  well-known  location  at  which  it  is  running  with 

requests  for  specific  adapter  components  (many  to  one  interaction). 

The  AM  checks  against  its  repository  for  matches  and  returns  the  results  to  the 

clients  (one  to  many  interaction). 

10 

This  shows  the  interactions  between  QM  and  LM. 

The  QM  propagates  the  query  to  the  LM  (one  to  one  interaction). 

LM  returns  search  results  to  QM  (one  to  one  interaction). 

11 

This  shows  the  interactions  between  the  LM  of  one  ICB  and  target  LMs  of  other 

ICBs  with  which  this  LM  is  registered. 

The  LM  propagates  the  search  query  issued  by  the  QM  to  all  the  target  LMs  (one  to 

many  interaction). 

The  source  LM  receives  the  result  responses  from  these  target  LMs  (many  to  one 

interaction). 

Table  3.2.  Interactions  between  URDS  components 


37 


3.6  The  UniFrame  Approach  (UA) 

Figure  3.7  depicts  the  UniFrame  Approach  for  the  development  of  software  solutions 
for  DCS.  This  approach  as  proposed  in  [RAJOl]  has  two  levels: 

•  Component  Level  -  in  this  level,  different  components  are  created  by  developers, 
tested  and  verified  from  the  point  of  view  of  QoS,  and  then  deployed  on  the 
network 

•  System  Level  -this  level  concentrates  on  assembling  a  collection  of  components, 
each  with  a  specific  functionality  and  QoS,  and  semi-automatically  generates  the 
software  solution  for  the  particular  DCS  under  consideration. 


Figure  3.7.  UniFrame  Approach 
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The  two  levels  of  the  UA  and  associated  processes  as  described  in  [RAJOl]  are  provided 
below. 


3.6.1  Component  Development  and  Deployment  Process 

The  component  development  and  deployment  process  (illustrated  in  Figure  3.8) 
starts  with  a  UniFrame  specification  of  a  component  from  a  particular  domain  (see  Figure 

3.2) .  This  specification  is  in  a  natural  language-like  format  and  indicates  the 
computational,  cooperative,  and  auxiliary  aspects  and  QoS  metrics  of  the  component. 
This  informal  specification  is  then  refined  into  a  XML-based  specification  (see  Figure 

3.3) .  The  refinement  is  based  upon  the  theory  of  Two-Level  Grammar  (TLG)  natural 
language  specifications  [BAROO,  VAN65],  and  is  achieved  by  the  use  of  conventional 
natural  language  processing  techniques  (e.g.,  see  [JUROO])  and  a  domain  knowledge 
base.  The  refinement  process  also  includes  the  generation  of  interfaces,  which  may  then 
be  integrated  into  an  implementation  using  glue  and  wrapper  code.  The  interface 
incorporates  all  the  aspects  of  the  component,  as  required  by  the  UniFrame  specification. 
The  developer  provides  the  necessary  implementation  for  the  computational,  behavioral, 
and  QoS  methods.  This  process  is  followed  by  the  QoS  validation.  If  the  results  are 


Figure  3.8.  Component  Development  and  Deployment  Process 
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satisfactory  (as  required  by  the  QoS  eriteria)  then  the  eomponent  is  deployed  on  the 
network  and  eventually,  it  is  diseovered  by  one  or  more  Headhunters.  If  the  QoS 
eonstraints  are  not  met  then  either  the  developer  refines  the  UniFrame  speeifieation  or  the 
implementation  and  the  eyele  repeats. 


3.6.2  Automated  System  Generation  and  Evaluation  based  on  QoS 

In  general,  different  developers  will  provide  on  the  Internet  a  variety  of  possibly 
heterogeneous  eomponents  oriented  towards  a  speeifie  problem  domain.  Onee  all  the 
eomponents  neeessary  for  implementing  a  speeified  distributed  system  are  available,  then 
the  task  is  to  assemble  them  into  a  solution.  The  proposed  framework  takes  a  pragmatie 
approaeh,  based  on  Generative  Programming  [CZAOO],  to  eomponent-based 
programming.  It  is  assumed  that  the  generation  environment  will  be  built  around  a 
generative  domain  speeifie  model  (GDM)  supporting  eomponent-based  assembly.  The 
distinctive  features  of  the  proposed  approaeh  are  as  follows: 

The  developer  of  the  desired  distributed  system  presents  to  this  proeess  a  system 
query,  in  a  structured  form  of  natural  language  that  deseribes  the  required  characteristics 
of  the  distributed  system.  The  natural  language  proeessor  (NLP)  proeesses  the  query.  It 
does  this  aided  by  the  domain  knowledge  (sueh  as  key  coneepts  from  the  domain)  and  a 
knowledge-base  eontaining  the  UniFrame  deseription  of  the  eomponents  for  that  domain. 
From  this  query  a  set  of  seareh  parameters  is  generated  whieh  guides  Headhunter  agents 
for  a  eomponent  seareh  in  the  distributed  environment. 

The  framework,  with  the  help  of  the  infrastructure  deseribed  in  Section  3.5, 
collects  a  set  of  potential  components  for  that  domain,  eaeh  of  which  meets  the  QoS 
requirement  speeified  by  the  developer.  From  these,  the  developer,  or  a  program  aeting  as 
a  proxy  of  the  developer,  seleets  some  eomponents.  After  the  eomponents  are  fetehed,  the 
system  is  assembled  aeeording  to  the  generation  rules  embedded  in  the  generative  domain 
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model.  These  components  along  with  the  appropriate  adapters  (if  needed)  form  a 
software  implementation  of  the  distributed  system. 

Next  this  implementation  is  tested  using  event  traces  and  the  set  of  test  cases  to 
verify  that  it  meets  the  desired  QoS  criteria.  If  it  does  not,  it  is  discarded.  After  that, 
another  implementation  is  chosen  from  the  component  collection.  This  process  is 
repeated  until  an  optimal  (with  respect  to  the  QoS)  implementation  is  found,  or  until  the 
collection  is  exhausted.  In  the  latter  case,  the  process  may  request  additional  components 
or  it  may  attempt  to  refine  the  query  by  adding  more  information  about  the  desired 
solution  from  the  problem  domain.  Once  a  satisfactory  implementation  is  found,  it  is 
ready  for  deployment. 

The  process  for  automated  system  generation  and  evaluation  is  illustrated  in 
Figure  3.9. 


Figure  3.9.  Automated  System  Generation  and  Evaluation 


This  chapter  provided  an  overview  of  the  UniFrame  Approach  to  developing  a 
software  solution  for  a  DCS.  The  next  chapter  elaborates  on  the  URDS  architecture  by 
providing  a  detailed  high-level  description  of  the  URDS  components. 
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4.  URDS  ARCHITECTURE 


Chapter  3  provided  an  overview  to  the  UniFrame  Approach  and  the  URDS 
architecture.  The  present  chapter  describes  the  URDS  architecture  in  detail,  focusing  on 
the  high-level  design,  the  algorithms,  and  the  interactions  of  the  components  that 
comprise  the  URDS  architecture.  The  descriptions  in  this  chapter  are  at  a  conceptual  level 
and  are  not  tied  to  the  software  that  may  implement  the  architecture.  The  implementation 
specific  details  will  be  covered  in  Chapter  5. 

Figure  4.1  below  illustrates  the  components  of  the  URDS  architecture  outlined  in 


Chapter  3. 


Figure  4.1.  Components  of  the  URDS  Architecture 
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The  overview  of  the  URDS  arehiteeture  presented  in  Chapter  3  highlighted  the 
funetions  of  its  eomponents  namely:  i)  Internet  Component  Broker  (ICB)  whieh  is  a 
eolleetion  of  the  following  serviees  -  Query  Manager  (QM),  the  Domain  Seeurity 
Manager  (DSM),  Link  Manager  (LM)  and  Adapter  Manager  (AM)  ii)  Headhunters 
(HHs),  iii)  Meta-Repositories  (MR),  and  iv)  Aetive-Registries  (AR).  The  URDS 
arehiteeture  is  designed  to  diseover  heterogeneous  serviees  (SL.Sn).  The  elients/users  of 
the  URDS  system  are  the  Component  Assemblers,  System  Developers  or  System 
Integrators. 

The  following  subseetions  provide  the  high-level  design  details  and  algorithms  for 
eaeh  of  the  eomponents  in  the  URDS  arehiteeture. 


4.1  Internet  Component  Broker 

The  ICB  aets  as  an  all-pervasive  eomponent  broker  in  the  intereonneeted 
environment  providing  a  platform  for  the  diseovery  and  seamless  integration  of  disparate 
eomponents.  The  ICB  is  not  a  single  eomponent  but  is  a  eolleetion  of  serviees  eomprising 
of  the  Query  Manager  (QM),  the  Domain  Seeurity  Manager  (DSM),  Adapter  Manager 
(AM),  and  the  Link  Manager  (LM).  It  is  envisioned  that  there  will  be  a  fixed  number  of 
ICBs  deployed  at  well-known  loeations  hosted  by  eorporations  or  organizations 
supporting  the  UniFrame  initiative.  The  funetionality  of  the  ICB  is  similar  to  that  of  an 
Objeet  Request  Broker.  However,  the  ICB  has  eertain  key  features  that  are  unique.  It 
provides  eomponent  mappings  and  eomponent  model  adapters.  The  ICB,  in  eonjunetion 
with  Headhunters,  provides  the  infrastrueture  neeessary  for  scalable,  reliable,  and  secure 
discovery  and  registry  services  using  the  interconnected  infrastructure. 
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The  chief  functionalities  provided  by  the  ICB  are: 

•  Authenticate  the  principals  (Headhunters  and  Active  Registries)  in  the  system  and 
enforce  access  control  over  the  multicast  address  resources  for  a  domain  with  the 
help  of  the  Domain  Security  Manager  (DSM). 

•  Attempt  at  matchmaking  between  service  producers  and  consumers  with  the  help 
of  the  Headhunters  and  Query  Manager.  ICBs  may  cooperate  with  each  other  in 
order  to  increase  the  search  space  for  matchmaking.  The  cooperation  techniques 
of  ICBs  are  facilitated  through  the  Link  Manager  (LM). 

•  Act  as  a  mediator  between  two  components  adhering  to  different  component 
models.  The  mediation  capabilities  of  the  ICB  are  facilitated  through  the  Adapter 
Manager  (AM). 


4.1.1  Algorithm  for  ICB  Initialization 


In  the  algorithm  the  ICB  initializes  all  the  services  i.e.,  the  DSM,  QM,  LM  and 
AM  by  calling  their  initialization  routines. 


ICBINITIALIZATION 

CALL  DSMJNITIALIZATION (see  Algorithm  4.2.4. 1) 
CALL  QMJNITIALIZATION (SQQ  Algorithm  4.3. 3.1) 
CALL  LMJNITIALIZATION  (see  Algorithm  4.4. 1.1) 
CALL  AMJNITIALIZATION {SQQ  Algorithm  4.5. 1.1) 
END  ICB  INITIALIZATION 


The  following  subsections  provide  a  description  of  the  services  that  comprise  the 
ICB  and  their  contribution  to  providing  the  functionality  of  the  ICB. 
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4,2  Domain  Security  Manager  (DSM) 

The  URDS  discovery  protocol  is  based  on  periodic  multicast  announcements. 
Multicasting  [ERI94]  is  a  scalable  solution  for  the  group  communication.  However,  there 
are  various  security  issues  that  have  to  be  addressed  in  a  multicast  communication,  which 
do  not  arise  in  an  unicast  communication  [BAL95].  Security  threats  that  need  to  be 
addressed  are: 

•  Eavesdropping:  Since  multicast  addresses  are  not  private,  any  interested  host  can 
gain  access  to  the  multicast  data  by  just  becoming  a  member  of  that  group.  These 
kinds  of  security  attacks,  where  adversaries  try  to  gain  access  to  the  data  without 
really  disrupting  the  secure  multicast  protocol,  are  called  passive  attacks 
[STA95].  Potential  adversaries  may  also  use  the  data  collected  by  means  of 
eavesdropping  for  cryptanalysis  purposes  or  replay  the  data  at  a  later  time. 

•  Uncontrolled  Group  Access:  Since  access  to  the  group  is  not  controlled  in 
multicast  communication,  any  host  can  send  data  to  a  multicast  group  which  can 
cause  congestion  and  also  possibilities  of  a  Denial  Of  Service  attack  against  the 
group. 

•  Masquerading:  An  adversary  may  also  pose  as  another  host  that  is  a  member  of 
the  group.  This  enables  the  adversary  to  send  data,  receive  data  and  or  acquire 
access  to  the  secret-keys  by  posing  as  a  legitimate  member  of  the  group. 
Masquerading  is  a  form  of  active  attack. 

[DON99]  has  identified  the  following  components;  a)  Group  Membership  Control, 
b)  Secure  Communication,  and  c)  Key  Distribution  as  being  critical  to  effectively 
combating  the  security  threats  faced  in  multicast  communication.  The  following 
subsections  provide  a  brief  overview  of  these  security  mechanisms  and  explain  how  they 
are  incorporated  in  the  URDS  architecture  with  the  help  of  the  DSM. 
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4.2.1  Group  Membership  Control  (GMC) 

The  GMC  allows  only  authorized  hosts  to  join  a  multicast  group,  guarding 
against  otherwise  unilateral  subscriptions  by  arbitrary  hosts.  Group  membership  control 
can  be  exercised  in  two  ways: 

•  Access  Control  Lists:  Access  Control  Lists  allow  a  sender  or  an  authorized  third 
party  to  maintain  an  inclusion  or  an  exclusion  list  of  hosts  on  the  Internet 
corresponding  to  a  multicast  group.  Each  time  a  host  requests  to  join  the  multicast 
group,  the  sender  or  the  third  party  checks  with  the  access  control  list  to 
determine  whether  the  host  is  authorized  to  join  the  group.  [ACC97]  defines  an 
ACL  as  a  “data  structure  that  guards  access  to  resources”.  An  ACL  data  structure 
is  comprised  of  multiple  entries,  each  of  which  contains  a  set  of  permissions 
associated  with  a  particular  principal.  A  principal  represents  an  entity  such  as  an 
individual  user  or  a  group.  Each  entry  can  be  specified  as  being  either  positive 
(i.e.,  permissions  are  granted  to  the  associated  principal)  or  negative  (i.e., 
permissions  are  denied).  An  ACL  is  independent  of  the  authentication  scheme 
used  to  verily  the  validity  of  the  principal,  the  encryption  scheme  used  to  transmit 
the  data  across  the  network  and  the  resource  that  it  guards.  The  ACL  is  consulted 
after  the  authentication  phase.  After  the  principal  is  verified  to  be  an  authenticated 
user  in  the  system,  the  principal  may  access  resources.  Lor  each  such  resource,  the 
principal  may  or  may  not  be  granted  an  access  depending  on  the  permissions  that 
are  granted  to  the  principal  in  the  ACL  that  guards  the  resource.  The  ACL  can  be 
consulted  to  find  the  list  of  permissions  a  particular  principal  has  or  to  find  out 
whether  or  not  a  principal  is  granted  a  particular  permission  [ACC97].  The  details 
of  how  the  ACL  is  created  is  presented  in  the  algorithm  for  creating  ACL  entries 
in  subsection  4. 2.4. 2. 

•  Use  of  Capability  Certificates  [DON99]:  Capability  Certificates  are  issued  by  a 
designated  third  party  to  receivers.  Capability  Certificates  authenticate  the 
receivers  and  authorize  them  to  participate  in  a  multicast  group.  The  receivers 
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present  the  eapability  eertifieates  to  the  sender  or  an  authorized  third  party  to  gain 

aeeess  to  the  group. 

The  Group  Membership  Control  in  the  URDS  is  enforeed  through  the  use  of 
userid/password  authentieation  and  Aeeess  Control  Lists.  The  resourees  being  guarded 
are  the  multieast  addresses  alloeated  to  a  partieular  domain.  The  Domain  Seeurity 
Manager  (DSM)  serves  as  an  authorized  third  party,  whieh  maintains  an  inelusion  list  of 
Prineipals  (Headhunters  or  registries)  eorresponding  to  a  domain.  DSM  has  an  assoeiated 
repository  (database)  of  valid  prineipals,  passwords,  multieast  address  resourees  and 
domains.  Every  Headhunter  or  Aetive  Registry  is  assoeiated  with  a  domain.  The  Aetive 
Registries  assoeiated  with  a  domain  have  eomponents  registered  with  them,  whieh  belong 
to  that  domain.  The  Headhunter  in  turn  deteets  Registries,  whieh  belong  to  the  same 
domain  as  itself,  and  henee,  the  serviee  eomponents  deteeted  by  the  Headhunter  will 
belong  to  a  partieular  domain.  The  Prineipal  (authentieated  user),  is  allowed  aeeess  only 
to  the  multieast  address  mapped  to  the  domain  with  whieh  it  is  assoeiated.  A  Prineipal 
that  wishes  to  partieipate  in  the  diseovery  proeess  eontaets  the  DSM  with  its  eredentials 
(id,  password,  domain).  The  DSM  authentieates  the  prineipal  and  eheeks  its 
authorizations  against  the  domain  ACL.  The  DSM  returns  a  seeret-key  and  a  multieast 
address  mapped  to  the  eorresponding  domain  to  a  valid  prineipal.  The  DSM  Repository 
is  ereated  and  populated  by  an  administrator.  The  mappings  between  multieast  addresses 
and  domains,  and  users  and  domains  are  established  by  the  organization  providing  the 
DSM  serviee. 


4.2.2  Seeure  Communieation 

A  Seeure  eommunieation  ean  be  ensured  by  the  transmission  of  enerypted  data. 
There  are  several  eryptographie  meehanisms  such  as  secret-key  [STA95]  and  public-key 
[STA95]  mechanisms. 
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In  the  URDS,  the  seeurity  of  transmitted  data  is  ensured  through  the  proeess  of 
Seeret-Key  Eneryption.  A  seeret-key  is  a  symmetrie  key  wherein  the  sender  and  reeeiver 
use  the  same  key  for  purposes  of  eneryption  and  deeryption.  The  DSM  is  responsible  for 
generating  a  unique  secret-key  for  each  domain. 


4.2.3  Key  Distribution 

A  Key  distribution  scheme  should  ensure  that  the  security  key  is  not  compromised 
and  the  communication  does  not  yield  to  active  security  attacks  such  as  masquerading. 
Many  schemes  exist  for  securing  key  distribution  such  as  Centralized  Flat  Key 
Management  Scheme  [BLU97,  CAR98,  GON94,  HAR97],  Hierarchical  Key 
Management  Scheme  [BAL96,  CAR98,  MIT97,  WAL97],  and  Distributed  Flat  Key 
Management  Scheme  [CAR98]. 

The  URDS  follows  a  Centralized  Flat  Key  Management  scheme  wherein  the 
DSM  serves  as  the  central  authority,  which  generates  and  distributes  the  secret-key  to 
authenticated  principals.  An  overview  of  the  DSM  Security  Enforcement  Protocol  is 
provided  below: 

•  DSM  acts  as  an  authorized  third  party  centralized  controller  for  the  secret-key 
distribution  and  the  multicast  address  allocation  to  Headhunters  and  Registries. 

•  Secret-Key  and  Address  allocation  is  domain  specific. 

•  Headhunter/Registries  communicate  to  DSM  their  authentication  credentials  (id, 
password,  domain). 

•  DSM  verifies  authentication  credentials  and  checks  permissions  against  the  ACE 
to  verify  the  user  access  to  that  domain. 

•  DSM  returns  to  the  authorized  users  a  multicast  address  picked  at  random  from 
the  list  of  addresses  allocated  to  that  domain  and  a  secret-key  generated  for  that 
domain. 
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•  In  case  the  prineipal  is  a  Headhunter  the  DSM  registers  the  contaet  information  of 
the  Headhunter  with  itself  The  QM  uses  this  information  for  the  query 
propagation. 


4.2.4  Algorithms  for  DSM  Functions 


Data  structures  used: 


Hash  table  ^ 

userDomainTable 

Mapping  between  principal  names  and  their 

corresponding  domains.  The  principal  name  serves  as  the 

key  for  this  mapping. 

Hash  table  domainTable 

Mapping  between  multicast  addresses  and  eorresponding 

domain  names.  The  multicast  address  serves  as  the  key  for 

this  mapping. 

Hash  table 

HHAddressA  Hoc  Table 

Mapping  between  multicast  addresses  allocated  to 

Headhunters  and  their  corresponding  domains.  The 

multicast  address  serves  as  the  key. 

Hash  table 

registeredHHTable 

Mapping  between  registered  Headhunter  locations  and  their 

domain.  The  registered  Headhunters  are  the  authorized 

principals  who  have  reeeived  a  multicast  address  and 

seeret-key  from  the  DSM. 

Hash  table  keyTable 

Mapping  between  domains  and  corresponding  Seeret-Keys. 

The  domain  names  serve  as  the  key. 

ACL^  domainACL 

ACL  of  usernames  and  their  assoeiated  permissions  (i.e. 

domains). 

Table  4.1.  Data  Strueture  for  DSM  functions 
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'  The  algorithms  in  this  section  and  succeeding  sections  use  the  hash  table  ADT  to 
represent  key-value  pair  mappings.  These  hash  tables  are  maintained  as  memory  resident 
tables. 

The  ACL  is  maintained  in  memory  after  creation. 

4.2.4. 1  Algorithm  for  DSM  Initialization 

The  DSM  configuration  process  comprises  of  setting  up  the  DSM  Repository 
with  the  information  about  the  domains,  associated  multicast  addresses,  authorized  users 
and  their  passwords.  The  information  is  stored  in  the  DSM  Repository  as  a  collection  of 
tables  (refer  sub  section  5. 3. 4. 1.1. 3  in  Chapter  5  for  implementation  specific  details  on 
these  tables).  The  DSM  configuration  is  performed  by  an  administrator.  The  DSM  upon 
initialization  creates  an  ACL  of  usernames  and  their  associated  permissions  and  generates 
secret-keys  for  each  of  the  domains.  It  then  actives  the  authentication  service,  which  can 
respond  to  remote  calls  by  the  Headhunters  and  active  registries.  New  entries  to  the 
DSM  Repository  are  added  on  an  as-needed  basis  and  the  in-memory  ACL  is  updated 
accordingly. 

DSMINITIALIZATION 

CREATE  DSM  REPOSITORY 
CALL  DSM  CREATE  ACL  ENTRIES 
CALL  DSM  GENERATE  SECRET  KEYS 
ACTIVA TE  DSM  AUTHENTICATION  SERVICE 
END  DSM  INITIALIZATION 


4.2. 4.2  Algorithm  for  Creating  Entries  in  the  ACL 

This  algorithm  outlines  the  process  for  creating  principals  and  permissions  using 
usernames  and  domain  names.  It  also  describes  the  process  for  creating  ACL  entries 
using  these  principal-permission  pairs  and  adding  these  entries  to  the  ACL. 
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DSMCREATEACLENTRIES 

EOAD  userDomainTable  ixom  DSM  Repository 

userNameList  =  GET  enumeration  of  user  names  from  userdomainTable 
WHIEE  userNameList  HAS  MORE  EEEMENTS 

username  =  GET  NEXT  EEEMENT  from  userNameList 
domainName  =  GET  value  in  userdomainTable  for  username  key. 
Create  a  new  PRINCIPAE  with  the  username 
Create  a  new  ACEENTRY  with  the  new  PRINCIPAE 
Create  a  new  PERMISSION  with  the  domainName 
Add  PERMISSION  to  ACEENTRY 
Add  ACEENTRY  to  domainACL 
END  WHIEE 

END  DSM  CREATE  ACE  ENTRIES 


4. 2.4. 3  Algorithm  for  Generating  Seeret-Keys 

This  algorithm  outlines  the  proeess  for  generating  seeret-keys  using  any  standard 
seeret-key-generating  algorithm  sueh  as  DES,  Triple  DES,  Blowfish,  ete.  A  seeret-key  is 
generated  for  eaeh  domain  and  stored  in  a  hash  table  ADT  of  domain  names  and  seeret- 
key  pairs. 

DSMGENERATESECRETKEYS 

domains  =  GET  enumeration  of  domain  names  from  domainTable 
//Create  a  key  generator  eomponent  eapable  of  generating  seeret-keys  that 
//  eorresponds  to  a  given  key  generating  algorithm. 
keyGenerator  = 

CREATE  a  new  KEYGENERATOR  with  keyGeneratingAlgorithm 
//Generate  a  seeret-key  for  eaeh  domain. 
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WHILE  domains  HAS  MORE  EEEMENTS 

domainName  =  GET  NEXT  EEEMENT  from  domains 
secretKey  =  GENERATEKEY  with  keyGenerator 
PUT  <  domainName,  secretKey  >  in  keyTable 
END  WHILE 

END  DSM  GENERATE  SECRET  KEYS 


4.2.4.4  Algorithm  for  Authentication,  and  Secret-Key  and  Multicast  Address  Distribution 

This  algorithm  outlines  the  proeess  for  authentieating  a  prineipal  by  verifying  their 
authentieation  eredentials  against  the  DSM  Repository.  The  authorization  of  user 
permissions  is  done  by  cheeking  against  the  ACL.  A  multicast  address  is  picked  at 
random  from  the  list  of  multicast  addresses  allocated  to  that  domain.  An  authenticated 
packet  comprising  of  the  multicast  address  and  secret-key  for  the  domain  is  returned  to 
the  user. 

DSMAUTHENTICATIONSERVICE 

IN:  user  Type,  userName,  password,  contactLocation,  domain 
OUT:  authenticatedPacket  containing  multicast  Address  and  secretKey 
WHILE  TRUE 

IE  contacted  by  user 

isUser Authenticated  = 

VAEIDATE  user  Type,  userName,  password  against 
DSM_Repository. 

IE  isUserAuthenticated  EQUALS  TRUE 

CREATE  a  new  PRINCIPAE  for  the  username 
CREATE  a  new  PERMISSION  for  the  domain 
isUserAuthorized  =  CHECK  PRINCIPAL’S  PERMISSION 


in  domainACL 
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IF  isUser Authorized  EQUALS  TRUE 

/*  If  a  multicast  address  for  a  domain  is  requested 
by  a  Registry  and  there  are  addresses  alloeated  to 
Headhunters  for  this  domain  then  get  the  list  of 
domainAddresses  from  HHAddressAllocTable 
eorresponding  to  domainName  and  seleet  an  address 
at  random  from  this  list.  */ 

IF  (userType  EQUALS  “Registry”)  AND 
{HHAddressAllocTable  CONTAINS  VALUE 
domainName  ) 

mcastaddressList  = 

GET  the  list  of  domainAddresses  from 
HHAddressAllocTable  eorresponding  to 
domainName. 
domainAddress  = 

SELECT  RANDOM  address  from 
mcastaddressList 

ELSE 

/*  If  a  HeadHunter/Registry  requests 
multieast  address  for  a  domain  piek  an 
address  at  random  from  the  domainTable- 
i.e.  from  the  list  of  addresses  alloeated  to 
this  domain.  */ 
mcastaddressList  = 

GET  list  of  domainAddresses  from 
domainTable  eorresponding  to 

domainName. 
domainAddress  = 

SELECT  RANDOM  address  from 
mcastaddressList 
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IF  (userType  EQUALS  “Headhunter”) 

/*  Maintain  a  list  of  Headhunter  eontact 
loeations  */ 

VUT<contactLocation,  domainName>  in 
registeredHHTable 

/*  Maintain  a  list  of  addresses-domain 
mappings  alloeated  to  Headhunters.  */ 

PUT  <domainAddress,  domainName>  in 
HHAddressAUocTable 
ENDIF 
ENDIF 
secretKey  = 

GET  seeretkey  from  keyTable  eorresponding  to 

domaitiName 

CREATE  authenticatedPacket  and  Send 
Response  to  user 
ENDIF  //authorized  user 
ENDIF  //authentieated  user 
ENDIF  //eontacted  by  user 
END  WHILE 

END  DSM  AUTHENTICATION  SERVICE 


4.2.4.5  Algorithm  for  Withdrawing  Headhunters  from  DSM 

This  algorithm  outlines  the  proeess  for  withdrawing  a  Headhunter  from  the  DSM. 

DSMWITHDRAW 

IN:  HeadhunterLocation 

REMOVE  key-value  pair  eorresponding  to  HeadhunterLocation  from 
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RegisteredHHTable 
END  DSM  WITHDRAW 


4,3  Query  Manager  (QM) 

The  QM  is  responsible  for  finding  services  matching  the  client’s  query  requests. 
The  QM  uses  a  parser  [LEE02]  to  translate  a  service  consumer’s  natural  language-like 
query  into  an  XML-based  query.  The  QM  parses  the  XML  based  query  to  generate  a 
structured  query  language  statement  and  dispatches  this  query  to  the  ‘appropriate’ 
Headhunters  (determined  by  the  domain  of  the  query).  Requests  for  service  components 
belonging  to  a  specific  domain  will  be  dispatched  to  Headhunters  belonging  to  that 
domain  and  the  Headhunters  return  the  list  of  matching  service  providers  to  the  QM.  The 
QM  obtains  the  list  of  registered  Headhunters  from  the  DSM.  The  QM  in  conjunction 
with  the  EM  is  also  responsible  for  propagating  the  queries  to  other  linked  ICBs. 

The  QM  is  configured  by  an  administrator  with  a  Query  Propagation  Policy.  The 
QM  propagates  a  query  to  the  EM  based  on  the  Query  Propagation  Policy  specified.  The 
Query  Propagation  Policy  can  be  specified  as: 

•  If  No  Local:  Propagate  a  query  to  the  EM  only  if  there  are  no  local  search  results 
that  satisfy  the  query 

•  Always:  Always  propagate  a  query  to  the  EM 


4.3.1  Result  Selection  Process 


The  total  search  space  for  a  service  selection  may  be  very  large;  including 
services  from  all  Headhunters  associated  with  a  particular  Internet  Component  Broker 
(ICB)  and  all  linked  ICBs.  The  QM  uses  policies  (explained  in  subsection  4. 3. 1.1)  to 
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identify  a  set  SI  of  services  to  return.  The  QoS  type  and  constraint  (explained  in 
subsection  4. 3. 1.2)  are  applied  to  SI  to  produce  the  set  S2  that  satisfies  the  service  type 
and  constraint.  Then  this  can  be  is  ordered  using  the  preferences  specified  in  the  query 
(explained  in  subsection  4. 3. 1.3),  before  returning  the  services  to  the  service  requesters. 


4. 3. 1.1  Policies 


Policies  provide  information  to  affect  QM  behavior  at  run  time.  Policies  are 
represented  as  name-value  pairs.  Policies  can  be  grouped  into  two  categories:  a)  policies 
that  scope  the  extent  of  a  search,  and  b)  policies  that  determine  the  functionality  applied 
to  an  operation.  The  examples  for  search  scoping  policies  are  i)  upper  bound  of  offers  to 
be  searched,  ii)  upper  bound  of  offers  to  be  returned,  and  iii)  upper  bound  of  matched 
offers  to  be  ordered,  etc.  Examples  for  functionality  scoping  policies  are  minimum 
number  of  QoS  types  desired  to  be  matched. 


4. 3. 1.2  Constraints 


Service  Requesters  use  QoS  types  and  constraints  to  select  the  set  of  service 
offers  in  which  they  have  an  interest.  Constraints  are  described  by  the  3 -tuple 
<QoS-type-name,  Operators,  Literals>  where  QoS-type-name  specifies  the  QoS  metric 
on  which  the  constraint  is  being  applied.  Operators  are  comparison,  boolean  connective, 
substring,  arithmetic  operators,  etc.,  and  Literals  are  the  numeric/string/boolean  values 
corresponding  to  the  QoS  types.  Example:  <availability,  >,  50> 


4. 3. 1.3  Preferences 


Preferences  are  applied  to  the  set  of  services  matched  by  application  of  the  QoS 
type,  constraint  expression,  and  various  policies.  The  application  of  the  preferences  can 
determine  the  order  used  to  return  matched  services  to  the  service  requesters.  Preferences 
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are  associated  with  the  2-tuple  <Sort  Order,  QOS-type-name  >.  The  sort  order  can  be 
specified  as  max  (matched  offers  are  returned  in  descending  order  of  QoS-type  values), 
min  (matched  offers  are  returned  in  ascending  order  of  QoS-type  values),  and  first 
(matched  offers  are  returned  in  the  order  they  are  discovered). 


4.3.2  Query  Handling  Process 

The  QM  Query  Request  Handling  Protocol  consists  of  the  following  steps: 

•  Parse  a  component  assembler’s/system  integrator’s  natural  language-like  query 
and  extract  the  keywords  and  phrases  pertaining  to  various  attributes  of  the 
components  UniFrame  specification. 

•  Extract  the  consumer-specified  constraints,  preferences  and  policies  to  be  applied 
to  the  various  attributes. 

•  Compose  the  extracted  information  into  an  XML-based  query. 

•  Translate  the  XML-based  query  to  a  structured  query  language  statement. 

•  Dispatch  this  structured  query  to  all  the  Headhunters  associated  with  the  domain 
on  which  the  search  is  being  performed  and  also  forward  the  query  based  on  the 
Query  Propagation  Policy  to  the  Link  Manager,  which  will  propagate  the  query 
to  other  ICBs. 

•  The  Headhunters  will  query  associated  Meta-Repositories  and  return  a  list 
(possibly  non-empty)  of  components  matching  the  search  criteria  to  the  QM, 
which  is  returned  to  the  system  integrator  making  the  query. 

•  QM  will  wait  for  a  specified  time  period  for  results  to  be  returned  from  the 
Headhunters/other  ICBs  before  timing  out.  A  default  timeout  period  for  a  session 
is  configured  into  the  QM  by  an  administrator.  A  session  constitutes  each  new 
query  operation  serviced. 

•  The  system  integrator  has  the  option  to  specify  search-scoping  policies  to  affect 
the  time  spent  on  the  search  process. 
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4.3.3  Algorithms  for  QM  Functions 


Data  structures  used; 


Entity^  queryEntity 

An  entity,  whieh  holds  all  the  attributes 

eorresponding  to  the  elient’ s  query  request  with 

aeeessors  for  aeeessing  the  attributes.  The 

attributes  of  the  queryEntity  inelude  the 

eomputational,  eooperational,  and  auxiliary 

attributes,  QoS  Metries,  QM  Polieies, 

Constraints,  and  Preferenees. 

Hash  table  resultTable 

Mapping  between  Component  IDs  and 

eomponents  holding  the  detailed  UniPrame 

Speeifieation. 

Table  4.2.  Data  Strueture  for  QM  funetions 


An  Entity  data  structure  is  a  eoneeptual  representation  for  an  objeet  and  holds  all  the 
attributes  that  deseribe  the  objeet  with  aceessors  for  aeeessing  these  attributes. 


4.3.3. 1  Algorithm  for  QM  Initialization 

The  QM  initialization  aetivates  the  elient  request  handler.  This  proeess  receives 
requests  from  elients  and  responds  with  results.  It  also  aetivates  the  query  propagation 
serviee,  whieh  ean  be  ealled  by  QM  or  LM. 

QMINITIALIZATION 

ACTIVATE  QM  CLIENT  REQUEST  HANDLER 
ACTIVATE  QM  PROPAGATE  QUERY 
ENDQMINITIALIZATION 


58 


4. 3. 3.2  Algorithm  for  HandlinE 


Requests  from  Clients 


This  algorithm  outlines  the  proeess  for  servieing  requests  from  Clients.  Clients 
eontact  the  QM  with  a  natural  language-like  query.  This  is  processed  into  an  XML  query, 
which  is  parsed  to  construct  an  entity  that  embodies  all  the  attributes  of  the  query.  The 
queryEntity  is  propagated  to  Headhunters,  which  are  associated  with  the  domain  of  the 
query  and  also  to  the  LM  based  on  the  results  obtained  from  the  Headhunters  and  the 
QueryPropagationPolicy  set  on  the  QM.  The  final  results  returned  from  the  Headhunters 
and  LMs  are  ordered  as  per  the  client’s  preferences  and  returned  to  the  client.  Each  client 
request  is  handled  as  a  separate  session.  The  session  timeout  period  is  configured  in  the 
QM. 


QMCLIENTREQUESTHANDLER 
IN:  naturalLanguageQuery 
OUT:  resultTable 

//Get  handle  to  DSM  and  EM  by  contacting  them  at  the  well-known  locations. 
dsm  =  EOOKUP  dsmLocation 
Im  =  EOOKUP  ImLocation 
WHIEE  TRUE 

IE  contacted  by  client  with  naturalLanguageQuery  Request 

/*  The  natural  language  query  is  parsed  and  keywords,  constraints, 
preferences,  and  policies  extracted  and  domain  knowledge  base  is 
applied  to  the  extracted  information  and  written  to  a  XML  Eile  */ 
Parse  naturalLanguageQuery  and  generate  XML  Pile. 

/*  The  XML  query  is  parsed  and  the  values  populated  into  an 
entity  which  contains  the  logic  to  construct  the  structured  query 
language  statement.  */ 
xmlQueryDocument  = 

Parse  XML  file  and  load  XML  document  into  memory. 

/*  The  QM  PROCESS  XML  QUERY  function  populates 
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the  queryEntity  instantiated  here.  */ 

CREATE  a  new  queryEntity 

CALE  QM  PROCESS  XML  QUERY with  xmlQueryDocument 
//Propagate  the  query  to  all  Headhunters  in  the  domain  of  query 
resultTable  = 

CAEE  QMPROP AGATE  QUERY  with  queryEntity 
/*  Cheek  if  the  seareh  scoping  policies  have  been  met 
example  if  upper  bound  of  offers  to  be  returned 
has  been  met  and  if  so  return  results  to  client.  */ 
searchScopePolicy  =  GET  search  scoping  policy  from  queryEntity 
IE  {searchScopePolicy  is  specified)  AND 
{searchScopePolicy  is  satisfied) 

resultTable  =  CALE  QM  ORDER  RE SUITS 

with  queryEntity,  resultTable 

Send  response  to  client  with  resultTable 

ENDIE 

/*  If  further  propagation  of  query  is  required 
Check  the  Query  Propogation  Policy  on  the  QM. 

If  QueryPropogationPolicy  =  “IfNoLocal”  and 
there  are  no  results  matching  the  search  criteria 
then  propagate  query. 

If  the  QueryPropogationPolicy  =  ‘Always  ” 
then  propagate  query  irrespective  of  whether  there  are  local 
search  results.  */ 

IP  {{resultTable  NOT  NULL))  OR 
( {QueryPropogationPolicy  EQUALS  “Always  ”)) 

results  =  CALL  LM  PROPAGATE  QUERY  on  Im 
with  queryEntity 
ADD  results  to  resultTable 


ENDIE 
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//Order  the  results  as  per  elient  preferenees 
resultTable  = 

CALL  QM  ORDER  RESULTS  with  queryEntity,  resultTable 
Send  response  to  client  with  resultTable 

ENDIF 
END  WHILE 

ENDQMCEIENTREQUESTHANDEER 


4. 3. 3. 3  Algorithm  for  Processing  XME 


This  algorithm  uses  recursion  to  parse  through  the  nodes  of  the  XME  tree,  extract 
the  node  values  and  store  these  values  in  the  queryEntity.  The  algorithm  starts  parsing  at 
the  root  node  element.  It  extracts  the  node  name  and  checks  if  the  node  name  matches 
any  attribute  in  queryEntity  and  populates  it  with  the  value  in  this  node.  It  then  finds  all 
the  children  of  that  node  and  repeats  the  process  through  recursion. 


QMPROCESSXMLQUERY 
IN:  nodeElement 

nodeName  =  GET  NODE  NAME  from  nodeElement 
EOR  each  attribute  in  queryEntity 

IE  nodeName  EQUALS  attribute 

nodeValue  =  GET  NODE  VALUE  from  nodeElement 
SET  attribute  value  in  queryEntity  to  nodeValue 

ENDIF 

ENDFOR 

//  Get  the  list  of  children  for  this  Node. 

NODEEIST  childrenList  =  GET  CHIEDNODES  for  nodeElement 
IF  childrenList  NOT  NULE 

//  For  every  child  node  in  the  list 
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FOR  i  =  0  to  LENGTH  of  childrenList 
childNode  =  chUdrenList[i] 

/*  Recurse  through  the  function  PROCESS  XML  QUERY 
passing  it  the  childNode  as  reference.*/ 

GALE  QM  PROCESS  XML  QUERY  with  chUdNode 
ENDEOR 

ENDIE 

ENDQMPROCESSXMEQUERY 


4.3.3.4  Algorithm  for  Propagating  Query  to  Headhunters 

This  algorithm  outlines  the  process  for  popagating  a  query  request  to  the 
Headhunters.  The  domain  of  a  client’s  query  and  the  search  scoping  policies  are  retrieved 
from  the  queryEntity.  The  DSM  is  contacted  to  obtain  a  list  of  registered  Headhunter 
locations  matching  this  domain.  The  query  is  then  propagated  to  each  Headhunter  and 
the  search  scoping  policies  are  checked  after  each  propagation  to  verify  whether  the 
policies  have  been  satisfied.  If  the  policies  are  satisfied  then  further  propagation  is 
terminated  and  the  results  are  ordered  as  per  client  preferences  and  returned. 

QMPROPAGATEQUERY 
IN:  queryEntity 
OUT:  resultTable 
WHITE  TRUE 

IE  contacted  by  this  QM  or  EM 

//The  queryEntity  stores  the  details  of  the  query  such  as  the  domain 

//  and  other  attributes  of  the  query. 

domain  =  GET  domainName  of  query  from  queryEntity 

/*  Get  location  list  of  registered  Headhunters  for  the  domain  of  the 

query.  */ 
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hhLocationList  =  GET  Headhunter  loeations  list  from  dsm  with 
domain 

//Propagate  the  query  to  eaeh  registered  Headhunter  in  the  domain. 

FOR  i=0  to  LENGTH  of  hhLocationList 

//Get  the  loeation  of  the  Headhunter 
hhlocation  =  hhLocationList [i] 

//Get  a  handle  to  the  Headhunter 
Headhunter  =  LOOKEiP  hhlocation 
//Propagate  query  to  eaeh  Headhunter. 
results  =  CALL  HH  EXECUTE  QUERY 
on  Headhunter  with  queryEntity 
ADD  results  to  resultTable 

ENDFOR 

RETURN  resultTable 

ENDIF 
END  WHILE 

ENDQMPROPAGATEQUERY 


4. 3. 3. 5  Algorithm  for  Ordering  Seareh  Results 

This  algorithm  outlines  the  proeess  for  retrieving  elient  preferenees  (sort  order 
aseending  or  deseending)  and  the  QoS  type  on  whieh  the  ordering  is  to  be  performed.  The 
results  are  then  ordered  aeeordingly  and  returned. 

QMORDERRESULTS 

IN:  queryEntity,  resultTable 
OUT:  resultTable 

orderPreference  =  GET  ordering  preferenee  from  queryEntity 
qosTypeToOrder  =  GET  the  QoS-Type-Name  to  order  by  from  queryEntity 
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IF  orderPreference  NOT  NULL  //  If  an  order  preference  was  specified 
resultTable=  SORT  elements  of  resultTable  on  qosTypeToOrder 
RETURN  resultTable 

ELSE 

RETURN  resultTable  to  client 

ENDIE 

ENDQMORDERRESUETS 


4.3.3.6  Algorithm  for  Generating  Structured  Query  Eanguage  (SQE)  Statement 

This  algorithm  forms  a  part  of  the  operations  performed  by  queryEntity.  This 
algorithm  outlines  the  process  for  generating  a  SQE  statement  based  on  the  attributes 
extracted  from  the  client’s  query.  These  attributes  are  captured  in  the  queryEntity.  The 
attribute  names,  values  and  constraints  stored  in  the  query  entity  are  built  into  a  SQL 
statement. 


QEGENERATESQLQUERY 
IN:  queryEntity 
OUT:  sqlQuery 

attributeList  =  GET  all  attributes  in  queryEntity 
EOR  i=0  to  EENGTH  of  attributeList 
attribute  =  attributeList [i] 

IE  attribute  is  selected  as  search  parameter 

attributeValue  =  GET  value  of  this  attribute  from  queryEntity 
attributeConstraint  =  GET  constraint  value  from  queryEntity 
CONCATENATE  to  BUIED  SQE  query  the 
attribute,  attributeConstraint,  and  attributeValue 


ENDIE 
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ENDFOR 
RETURN  sqlQuery 

ENDQEGENERATESQEQUERY 


4,4  Eink  Manager  (EM) 

ICBs  are  linked  to  form  a  Federation  of  Brokers  (refer  Figure  3.5  in  Chapter  3)  in 
order  to  allow  for  an  effeetive  utilization  of  the  distributed  offer  space.  ICBs  may 
propagate  the  seareh  query  issued  by  the  system  integrator  to  other  ICBs  to  which  they 
are  linked.  This  linkage  of  ICBs  makes  the  offer  spaces  of  the  linked  ICBs  implicitly 
available  to  the  ICB’s  own  clients. 

The  EM  performs  the  functions  of  the  ICB  associated  with  establishing  links  and 
propagating  the  queries.  Links  represent  paths  for  propagation  of  queries  from  a  source 
ICB  to  a  target  ICB.  Each  link  is  unidirectional  and  corresponds  to  an  edge  in  a  directed 
graph,  in  which  the  vertices  are  EMs. 

The  Eink  Manager  supports  the  following  operations: 

•  Query:  The  query  operation  is  responsible  for  propagating  the  query  from  the 
source  EM  to  the  list  of  Target  EMs  maintained  with  the  Source  EM. 

•  Failure  Detection:  This  involves  keeping  track  of  EMs,  which  may  no  longer  be 
active  due  to  network  failure,  node  failure,  etc.  Periodically  (TPunicast  ms  -  time 
period  between  successive  failure  detection  cycles)  the  source  EM  contacts  the 
list  of  target  EMs  with  which  it  is  configured,  to  re-establish  links  and  to  create  a 
fresh  target  EM  list.  If  the  target  EMs  respond  to  the  source  EM,  it  means  the 
Target  EM  is  ‘alive’  to  service  requests.  This  target  EM  location  is  added  to  the 
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list  of  target  LMs  to  whom  requests  will  be  propagated  in  that  cycle.  If  the  target 
LMs  do  not  respond  then  that  target  LM  may  have  failed.  During  subsequent 
cycles  if  a  previously  failed  target  LM  is  now  alive  to  service  requests,  then  it  is 
added  to  the  list  of  LMs  to  receive  queries  for  that  cycle. 


4.4.1  Algorithms  for  LM  Functions 


Data  structures  used: 


List  aliveTargetLMList 

List  of  Target  LM  locations,  which  are 

alive  and  can  service  query  requests. 

List  targetLMList 

List  of  locations  of  LM’s  with  which  this 

LM  registers.  This  can  be  specified  with 

the  configuration  information  at  LM 

initialization. 

Table  4.3.  Data  Structure  for  LM  functions 


4. 4. LI  Algorithm  for  LM  Initialization 

The  LM  upon  initialization  establishes  links  with  the  list  of  target  LMs  passed  to 
it  as  configuration  information.  It  starts  failure  detection  processes,  which  stay  alive  as  an 
active  processes  and  runs  periodically  in  the  background.  It  also  activates  the  query 
propagation  and  link  checking  processes,  which  can  be  called  from  remote  LMs. 

LMINITIALIZATION 
IN:  targetLMList 
CALL  LM  ESTABLISH  LINKS 
START  LM  FAILURE  DETECTION 
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ACTIVATE  LM  PROPAGATE  QUERY 
ACTIVATE  LMCHECKLINK 
END  EM  INITIALIZATION 


AAA. 2  Algorithm  for  Establishing  Links  with  Target  LMs 

This  algorithm  outlines  the  proeess  followed  by  the  EM  for  establishing  links  with 
Target  LMs.  The  EM  steps  through  the  list  of  target  EM  loeations  it  is  eonfigured  with 
and  eontaets  each  of  these  target  LMs.  If  the  target  EM  responds,  then  this  target  EM 
location  is  added  to  the  aliveTargetLMList,  which  maintains  a  list  of  all  alive  target  LMs 
to  whom  the  queries  will  be  propagated.  If  the  EM  does  not  repond  due  to  link  or  node 
failure  then  the  failed  target  EM  address  is  not  stored. 

LMESTABLISHLINKS 

CREATE  aliveTargetLMList 

//Contact  the  LMs  specified  in  configuration. 

EOR  i=0  to  LENGTH  targetLMList 

targetLMLocation  =  targetLMList [i] 
targetLM  =  LOOKUP  targetLMLocation 
isAlive  =  CALL  LM  CHECK  LINK  on  targetLM 
//If  target  EM  is  alive  then  add  this  target  EM  location 
//to  the  list. 

IE  isAlive 

//Maintain  a  list  of  LMs  with  whom  registration  was 
//  successful 

ADD  targetLMLocation  to  aliveTargetLMList 

ENDIE 

ENDEOR 

END  EM  ESTABLISH  LINKS 
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4.4. 1,3  Algorithm  for  Checking  whether  Links  can  be  Established 

The  LM  contacts  target  LMs  to  check  if  they  are  functioning.  When  contacted  by 
a  source  LM  the  target  LM  returns  a  “true”  response  indicating  it  is  alive  to  service 
requests. 

LMCHECKLINK 
OUT:  is  Alive 
WHILE  TRUE 

IE  contacted  by  LM 

RETURN  TRUE 

ENDIE 

ENDIE 

END  EM  CHECK  EINK 


4.4. 1 .4  Algorithm  for  Propagating  a  Query  by  the  EM 

This  algorithm  outlines  the  process  for  receiving  a  query  from  the  QM  in  the  same 
ICB  and  propagating  it  to  EMs  in  other  ICBs  or  receiving  a  query  from  EMs  in  other 
ICBs  and  propagating  query  to  the  QM  in  the  same  ICB.  The  determination  of  where  the 
query  is  coming  from  is  made  based  on  the  value  of  the  requestID  attribute  in 
query  Entity.  The  requestID  is  a  String  value,  which  is  set  to  the  value  “LinkManager  ”  if 
the  query  is  received  from  an  external  EM  or  holds  a  default  value  of  “Query Manager” 
when  the  queryEntity  is  instantiated  by  the  QM  for  propagation.  When  the  EM  receives  a 
query  it  inspects  the  value  of  the  requestID  attribute.  If  the  requestID  is  set  to 
“Query Manager”  it  means  the  query  has  originated  from  a  QM  in  the  same  ICB  and 


68 

needs  to  be  propagated  to  other  LMs.  If  the  requestID  set  to  “LinkManager”,  it  means  the 
query  is  eoming  from  another  LM  and  needs  to  be  propagated  to  the  QM  in  the  same  ICB 
as  the  LM. 

LMPROPAGATEQUERY 
IN:  query  Entity 
OUT:  resultTable 
WHIEE  TRUE 

IE  eontaeted  by  QM  in  same  ICB  or  EM  in  different  ICB 
requestID  =  GET  requestID  from  queryEntity 
//If  the  propagation  request  has  eome  from  EM  in  the  different  ICB 
IE  {requestID  EQUALS  “LinkManager”) 

//Propagate  the  request  to  QM  loeated  in  same  ICB  as  LM. 
resultTable  =  CALL  QM  PROPAGATE  QUERY  on  qm 
with  queryEntity 
RETURN  resultTable 

//If  the  propagation  request  has  eome  from  QM  in  the  same 
//ICB  as  EM.  The  requestID  would  be  set  to  “QueryManager”. 

ELSE 

//This  query  will  now  be  propagated  to  target  EMs 
//henee  the  requestID  parameter  has  to  refleet  this 
//that  it  is  eoming  from  a  EM. 

SET  requestID  =  “LinkManager  ”  in  queryEntity 
CREATE  resultTable 

//Get  list  of  all  alive  EMs  to  whom  the  query  ean  be 
//propagated. 

EOR  i  =  0  to  EENGTH  of  aliveTargetLMList 

targetLMLocation  =  aliveTargetLMList\i] 
targetLM  =  EOOKUP  targetLMLocation 
results  = 
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CALL  LMPROP AG  ATE  QUERY  on  targetLM 
with  queryEntity 
ADD  results  to  resultTable 
ENDFOR 

RETURN  resultTable 

ENDIF 

ENDIF 
END  WHILE 

ENDEMPROPAGATEQUERY 


4.4. 1.4  Algorithm  for  Failure  Detection  of  Target  EMs 

The  EMs  periodically  check  whether  all  the  target  EMs  maintained  in  the  target 
EM  list  are  still  alive  by  establishing  contact  with  the  target  EMs. 

EMFAIEUREDETECTION 
WHIEE  TRUE 

CAFE  LM  ESTABLISH  LINKS 
H  Periodically  (TPunicast  millisecs)  refresh  links  so  that 
//a  list  of ‘alive’  Target  EMs  is  maintained.  The  optimal 
//  TPunicast  time  is  determined  based  on  experimentation. 

SEEEP  TPunicast 
END  WHIEE 

END  EM  FAIEURE  DETECTION 
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4,5  Adapter  Manager  (AM) 

The  AM  serves  as  a  registry/lookup  service  for  clients  seeking  adapter 
components.  The  adapter  components  register  with  the  AM  and  while  doing  so  they 
indicate  their  specialization  (i.e.,  which  heterogeneous  component  models  they  can 
bridge  efficiently).  System  Integrators  contact  the  AM  to  search  for  adapter  components 
matching  their  needs.  The  AM  utilizes  adapter  technology,  each  adapter  component 
providing  translation  capabilities  for  specific  component  architectures.  Thus,  a 
computational  aspect  of  the  adapter  component  indicates  the  models  for  which  it  provides 
interoperability.  The  adapter  components  achieve  interoperability  using  the  principles  of 
wrap  and  glue  technology  [LUQOl].  A  reliable,  and  cost-effective  development  of  wrap 
and  glue  is  realized  by  the  automatic  generation  of  glue  and  wrappers  based  on 
component  specifications.  Wrapper  software  provides  a  common  message-passing 
interface  for  components  that  frees  developers  from  the  error  prone  tasks  of 
implementing  interface  and  data  conversion  for  individual  components.  The  glue 
software  schedules  time-constrained  actions  and  carries  out  the  actual  communication 
between  components. 


4.5.1  Algorithms  for  AM  Functions 


Data  structures  used: 


Entity  adapterQueryEntity 

An  entity,  which  holds  all  the  attributes 

corresponding  to  the  client’s  query  request  with 

access  modifiers  for  accessing  the  attributes. 

List  adapterResults 

List  of  adapter  components  matching  the  query 

requirements. 

Table  4.4.  Data  Structure  for  AM  functions 
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4.5. 1.1  Algorithm  for  AM  Initialization 

The  AM  on  initialization  creates  the  AM  REPOSITORY  where  the  adapter 
component  service  information  is  stored.  It  activates  the  client  request  handler,  which 
services  client’s  query  requests  for  adapter  components  and  the  adapter  registration 
handler  process,  which  receives  calls  from  remote  services  to  register  them  with  the  AM. 

AMINITIALIZATION 

CREATE  AM  REPOSITORY 
ACTIVATE  AM_CLIENT  REQUEST  HANDLER 
ACTIVATE  AM_SER  VICE  REGISTRA  TION  HANDLER 
END  AM  INITIALIZATION 


4. 5. 1.2  Algorithm  for  Handling  Client  Requests  for  Adapters 

The  AM  receives  natural  language-like  query  requests  for  adapter  components 
from  clients.  The  process  of  parsing  the  query  and  generating  a  structured  query  language 
statement  is  similar  to  that  used  in  the  QM  (Algorithm  QM  PROCESS  XML  QUERY 
and  QE  GENERATE  SQL  QUERY).  The  AM  executes  the  resultant  SQL  query  against 
the  AM  Repository  and  obtains  the  list  of  adapter  components  matching  the  search 
criteria. 

AMCLIENTREQUESTHANDLER 

IN:  naturalLanguageAdapterQuery 
OUT:  adapterResults 

WHILE  TRUE 

IE  contacted  by  client  with  REQUEST  for  adapter  components 
//  Refer  algorithms  QM  PROCESS  XML  QUERY and 
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//  QE  GENERATE  SQL  QUERY 
sqlQuery  =  PROCESS  naturalLanguageAdapterQuery 
adapterResults  =  EXECUTE  QUERY  sqlQuery  on 
AMREPOSITORY 
return  adapterResults  to  Client 

ENDIE 
END  WHILE 

ENDAMCLIENTREQUESTHANDLER 


4.5. 1.3  Algorithm  for  Registering  Adapter  Components 

The  AM  reeeives  the  XML  based  specifieation  of  the  adapter  components  and 
parses  these  specifications  to  extract  the  data  and  stores  this  information  in  the 
AMREPOSITORY. 

AMADAPTERREGISTRATIONHANDLER 
IN:  adapterComponentSpecification 
WHILE  TRUE 

IE  contacted  by  adapter  component  with  REQUEST  for  registration 

STORE  adapterComponentSpecification 'm  AM  REPOSITORY 

ENDIE 
END  WHILE 

END  AM  ADAPTER  REGISTRATION  HANDLER 
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4.6  Headhunters 


Another  critical  component  of  URDS  is  a  Headhunter.  The  Headhunters  perform 
the  following  tasks:  a)  Service  Discovery:  detect  the  presence  of  service  providers 
(Exporters),  b)  register  the  functionality  of  these  service  providers,  and  c)  return  a  list  of 
service  providers  to  the  ICB  that  matches  the  requirements  of  the  consumer  (Importers) 
requests  forwarded  by  the  QM. 

The  service  discovery  process  performs  the  search  based  on  multicasting. 

Once  deployed  in  the  UniFrame  environment,  the  Headhunters  periodically  (TP^cast  ms  - 
time  period  between  successive  multicast  cycles)  multicast  their  presence  (location 
address  of  the  Headhunter)  to  a  multicast  group.  The  multicast  group  address  is  obtained 
from  the  DSM.  The  active  registries  (extended  native  registries),  which  also  obtain  a 
multicast  group  address  from  the  DSM,  listen  for  multicast  messages  from  Headhunters 
on  these  multicast  groups.  When  Active  Registries  receive  a  multicast  message  from  a 
Headhunter  with  its  location  they  respond  to  the  message  by  unicasting  their  location 
information  to  the  Headhunter.  The  Headhunters  maintain  a  cache  of  the  pairs  <registry 
address,  (time-stamp  of  receipt)>.  The  Headhunter  uses  the  registry  location 
information  received  to  query  the  Registries  for  the  component  information  of  service 
providers  they  contain  in  order  to  register  the  service  information  details  with  itself 
During  the  registration,  the  Headhunter  stores  into  the  meta-repository  all  the  details  of 
the  service  providers,  including  the  UniFrame  specifications.  It  uses  this  information 
during  a  matching-making  process  where  it  tries  to  find  services  that  satisfy  the 
computational,  cooperational,  auxiliary  attributes  and  QoS  metrics  specified  in  the  search 
query.  A  component  may  be  registered  with  multiple  Headhunters.  The  functionality  of 
Headhunters  makes  it  necessary  for  them  to  communicate  with  Active  Registries 
belonging  to  any  model,  implying  that  the  cooperative  aspect  of  Headhunters  be 
universal. 
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The  two  main  issues  that  need  to  be  handled  by  the  Headhunter  apart  from  the 
stated  funetions  are: 

•  Failure  Detection:  Failure  deteetion  (FD)  involves  keeping  traek  of  serviee 
exporter  eomponents  whieh  may  no  longer  be  aetive  in  the  system  for  various 
reasons  ineluding  voluntary  withdrawal  from  their  respeetive  registries,  network 
failure,  node  failure,  ete.  The  failure  deteetion  in  the  Headhunter  is  done  at  the 
level  of  deteeting  failure  of  the  aetive  registries,  whieh  hold  the  serviee  exporter 
eomponents.  The  Headhunter  keeps  traek  of  the  time  at  whieh  it  obtains  registry 
loeation  information  from  various  aetive  registries.  At  regular  time  intervals 
(TPpurge  ms  -  time  period  between  sueeessive  purge  eyeles)  the  Headhunter  notes 
the  ‘freshness’  of  the  information  it  holds  and  purges  the  registry  information, 
whieh  it  deems  to  be  ‘stale’.  ‘Fresh’  or  ‘Stale’  are  determined  based  on  the  time 
elapsed  between  the  reeeipt  of  the  registry  address  through  unieast 
eommunieation  (77)  and  the  eurrent  time  (77).  If  the  elapsed  time  is  greater  than  2 
purge  eyeles  (i.e.  (77  -  77  )>  2TPpurge)  then  it  signifies  that  the  registry  is  not 
responding  and  may  be  dead  or  ‘stale’,  else  the  registry  information  is  deemed  to 
be  ‘fresh’.  This  is  essentially  based  on  the  prineiple  that  if  a  registry  is  still  aetive 
in  the  system  it  will  respond  to  the  Headhunter  with  its  loeation  information  and 
thus  have  a  later  timestamp.  A  registry  whieh  for  whatever  reason  is  unable  to 
eontaet  the  Headhunter  with  its  information  will  hold  a  ‘stale’  timestamp  and  it 
will  be  assumed  that  all  serviee  exporter  eomponents  held  by  this  registry  are  no 
longer  available  for  rendering  serviee. 

•  Multicast  Security:  This  involves  seeuring  the  multieast  data  transmission 
meehanism  from  seeurity  threats  sueh  as  eavesdropping,  and  masquerading.  The 
Headhunter  uses  Seeret-Key  Eneryption  to  ensure  seeurity  of  transmitted  data. 
The  seeret-key  used  is  a  symmetrie  key  wherein  the  sender  and  reeeiver  use  the 
same  key  for  purposes  of  eneryption  and  deeryption. 
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4.6.1  Algorithms  for  HH  Functions 


Data  structures  used; 


Hash  table  registryTable 

Mapping  between  Aetive  Registry  loeation 

addresses  and  the  timestamp  of  when  this 

loeation  address  information  was  reeeived 

by  the  Headhunter. 

Hash  table  componentTable 

Mapping  between  Component  IDs  and 

eomponents  holding  the  detailed  UniFrame 

Speeifieation. 

Table  4.5.  Data  Strueture  for  HH  funetions. 


4. 6. 1.1  Algorithm  for  HH  Initialization 

The  Headhunter  is  eonfigured  at  startup  by  the  deployer  with  the  DSM  loeation 
information,  domain  name,  username,  and  password.  The  Headhunter  upon  initialization 
eontaets  the  DSM  with  its  authentication  credentials  in  order  to  obtain  a  multieast  address 
and  seeret-key  for  its  domain.  The  Headhunter  then  ereates  the  meta-repository,  joins  the 
multieast  group  and  starts  the  proeesses  for  sending  multieast  communieation  and  failure 
deteetion,  whieh  exeeute  periodieally.  It  also  aetivates  the  proeess  to  reeeive  unieast 
eommunieation,  whieh  reeeives  ealls  from  remote  registries. 

HHINITIALIZATION 
IN:  DSMLocation 

I  I  Obtain  handle  to  DSM  which  runs  at  well-known  loeation 
dsm  =  LOOKUP  DSMLocation 

/*  Obtain  an  authentieated  paeket  by  eontaeting  the  DSM.  Pass  the  authentieation 
information  (userType,  userName,  password,  eontaetLoeation,  domain)  to  the 
DSM  and  wait  for  response  */ 
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authenticatedPacket  = 

CALL  DSM  AUTHENTICATION  SERVICE  on  dsm  with 
userType,  userName,  password,  contactLocation,  domain 
//Extract  multicast  address  and  secret-key  from  authentieatedPaeket. 
multicastAddress  =  GET  multicast  Address  from  authenticatedPacket 
secretKey  =  GET  secretKey  from  authenticatedPacket 
CREATE  META  REPOSITORY 

H  Onee  multieast  address  is  obtained  join  the  multieast  group. 

JOIN  multieast  group  with  multicastAddress 

HH  SEND  MULTICAST  COMMUNICATION 
START  HH  FAILURE  DETECTION 
ACTIVATE  HH_RECEIVE_UNICAST_COMMUNICA  TION 
END  HH  INITIALIZATION 


4.6. 1.2  Algorithm  for  Headhunter  Multieast  Announeements 

This  algorithm  outlines  the  proeess  for  periodie  enerypted  multieast  announeements  by 
the  Headhunter. 

HHSENDMULTICASTCOMMUNICATION 
WHILE  TRUE 

/*  Keep  multieasting  the  enerypted  eontaet  information  of  this  Headhunter 
at  regular  intervals  to  the  multieast  group  address,  whieh  has 
subseriptions  from  listeners,  whieh  are  the  aetive  registries.  */ 
encryptedHeadhunterLocation  =  ENCRYPT  secretKey{HscidhunterLocation} 
MUETICAST  encryptedHeadhunterLocation 

H  Put  the  multieasting  thread  to  sleep  for  TPmcast  millisees  before  the  next 
//  multieast. 

SEEEP  TPmcast 
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END  WHILE 

END  HH  SEND  MULTICAST  COMMUNICATION 


4.6. 1 .3  Algorithm  for  Receiving  Unicast  Communication  from  Active  Registries 

In  this  algorithm,  the  Headhunter  receives  the  registry  location  from  active  registries.  It 
then  computes  the  timestamp  of  receipt  and  stores  the  registry  location  and  timestamp  in 
a  hash  table.  It  then  uses  the  registry  location  information  it  has  received  to  contact  the 
registry  and  retrieve  component  information  available  with  the  registry  to  store  in  the 
meta-repository. 

HHRECEIVEUNICASTCOMMUNICATION 
IN:  vegistryLocation 
WHILE  TRUE 

IE  contacted  by  registry  with  registryLocation 

/*  Compute  the  timestamp  when  information  was  obtained 
The  timestamp  is  computed  as  the  number  of  millisecs  elapsed 
since  January  V\  1970  GMT.  */ 

Tr=  COMPUTE  CURRENT  TIMESTAMP 

/*  Add  the  registry  location  information  and  timestamp  to  the 

registry  table.*/ 

PUT  <regis  try  Location,  Tr>in  registryTable 
CALL  HH  POPULA TE  META  REPOSITOR Y with 
registryLocation 

ENDIE 
END  WHILE 

END  HH  RECEIVE  UNICAST  COMMUNICATION 
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4.6. 1.4  Algorithm  for  Populating  Meta  Repository 

This  algorithm  demonstrates  how  the  Headhunter  gets  a  handle  to  the  aetive  registries 
using  their  registry  loeation  and  eontaets  the  registries  to  retrieve  the  eomponent 
information,  whieh  it  stores  onto  the  meta-repository. 

HHPOPULATEMETAREPOSITORY 
IN:  registryLocation 

//  Get  handle  to  aetive  registry  using  its  registryLocation 
activeRegistry  =  EOOKEIP  registryLocation 
//  Obtain  the  component  data  stored  in  this  registry. 

componentTable  =  CALE  AR  GET  COMPONENT  DATA  on  activeRegistry 
H  Store  the  component  information  from  the  componentTable  into  the  Meta- 
//  Repository 

WHIEE  componentTable  HAS  MORE  EEEMENTS. 

componentinfo  =  GET  NEXT  EEEMENT  from  componentTable 
STORE  componentinfo  to  META  REPOSITORY 
END  WHILE 

END  HH  POPULATE  META  REPOSITORY 


4. 6. 1. 5  Algorithm  to  Retrieve  Search  Results  from  the  Meta-Repository 

This  algorithm  outlines  the  process  in  which  the  Headhunter  generates  the  SQL 
query  from  the  queryEntity  and  executes  this  query  against  the  meta-repository  to  retrieve 
the  list  of  components  matching  the  search  criteria. 
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HHEXECUTEQUERY 
IN:  queryEntity 
OUT:  resultTable 

sqlQuery  =  CALE  QE  GENERATE  SQL  QUERY  on  queryEntity 
resultTable  =  EXECUTE  QUERY  sqlQuery  on  META  REPOSITORY 
RETURN  resultTable 
ENDHHEXECUTEQUERY 


4.6. 1.6  Algorithm  to  Detect  Eailure  of  Active  Registries 

This  failure  detection  algorithm  of  the  Headhunter  involves  keeping  track  of 
active  registries  which  may  no  longer  be  alive.  The  Headhunter  records  the  timestamp  of 
responses  received  from  these  registries  and  periodically  checks  the  freshness  of  the 
registry  timestamps  purging  a  reference  to  all  the  ‘stale’  registries  and  also  deleting  all 
the  component  information  obtained  from  them. 

HHEAILUREDETECTION 
WHITE  TRUE 

/*  The  Headhunter  maintains  time  stamped  entries  of  responses 
received  from  the  active  registries.  Periodically  (TPpurge  millisecs)  a 
check  is  performed  to  verify  the  ‘currentness’  of  members  */ 

SEEEP  TPpurge 

Tc  =  COMPUTE  CURRENT  TIMESTAMP 

registryList  =GET  enumeration  of  locations  from  registryTable 

WHITE  registryList  HAS  MORE  EEEMENTS. 


registryLocation  =  GET  NEXT  EEEMENT  from  registryList 
Tr  =  GET  timestamp  in  registryTable  for  registryLocation 
IE  (T;  -  Tr  )>  2TPpurge 
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DELETE  components  in  repository  obtained  from  this 
registryLoeation 

REMOVE  <registryLocation,  Tr>  from  registryTable 

ENDIE 
END  WHILE 
END  WHILE 

END  HH  EAILURE  DETECTION 


4.6. 1 .7  Algorithm  for  Headhunter  Shutdown 

The  Headhunter  before  shutdown  withdraws  from  the  DSM,  leaves  the  multieast  group 
and  terminates  all  the  aetive  proeesses. 

HHSHUTDOWN 

//  Withdraw  Headhunter  registration  from  DSM 
CALL  DSM  WITHDRA  W  on  dsm  with  hhLocation 
I  I  Leave  multieast  group. 

LEAVE  multieast  group  at  multicastAddress 
I  I  Stop  all  aetive  threads  of  eontroL. 

STOP  HH_SEND_MULTICAST_COMMUNICA  TION 
STOP  HH  FAILURE  DETECTION 
HH  SHUTDOWN 


4,7  Meta-Repositry  (MR) 


The  Meta-Repository  is  a  data  store  that  holds  serviee  information  of  eomponents 
adhering  to  different  models.  The  Meta-repository  stores  the  Meta  level  serviee 
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information  comprising  of:  a)  Service  type  name,  b)  Details  of  its  informal  speeifioation, 
and  e)  Zero  or  more  QoS  values  for  that  serviee  for  each  of  the  components.  The 
implementation  of  a  Meta-Repository  is  database-oriented  and  all  the  eomponent 
information  is  stored  onto  a  database.  Using  a  database  implementation  provides  an 
opportunity  to  perform  searehes  for  components  matehing  the  seareh  eriteria  by  using  the 
inbuilt  searehing  teehniques.  The  Meta-Repository  is  a  passive  component,  i.e.,  a 
Headhunter  brings  information  and  stores  it  in  the  meta-repository. 


4.8  Aetive  Registry  (AR) 

The  native  registries  (e.g.,  RMl  Registry  or  CORBA  registry)  are  extended  to 
have  the  following  features: 

•  Activeness:  The  registries  are  modified  to  be  able  to  listen  to  multieast  messages 
from  the  Headhunter  and  respond  with  their  registry  location  information. 

•  Introspection  Capabilities:  The  registries  are  extended  to  not  only  keep  a  list  of 
component  URLs  of  those  eomponents  registered  with  them  but  also  their  detailed 
UniFrame  specifications.  This  is  achieved  by  querying  the  components  (using 
prineiples  of  introspeetion)  to  obtain  the  URL  of  their  XML  based  speeifieations. 
The  registries  parse  the  speeifieation  and  maintain  the  details  in  a  memory 
resident  table,  which  is  returned  to  the  Headhunter  upon  request. 
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4.8.1  Algorithms  for  AR  Functions 


Data  structures  used; 


Hash  table  componentTable 

Mapping  between  Component  ID  and 

eomponent  speeifieation  details. 

Entity  componentEntity 

An  entity,  whieh  ean  be  persisted  to  a 

repository  and  holds  all  the  attributes 

eorresponding  to  the  UniFrame 

speeifieation  with  access  modifiers  for 

aeeessing  the  attributes. 

Table  4.6.  Data  Strueture  for  AR  funetions. 


4.8. 1 . 1  Algorithm  for  AR  Initialization 

The  algorithm  for  AR  initialization  involves  eontaeting  the  DSM  for  an 
authentieated  packet  of  the  multieast  address  and  the  seeret-key.  Using  the  multieast 
address  the  AR  joins  the  multieast  group  and  starts  listening  for  multieast  eommunication 
from  the  Headhunters  on  this  multieast  group. 

ARINITIALIZATION 
IN:  DSMLocation 

1 1  Obtain  handle  to  DSM  whieh  runs  at  well-known  loeation 
dsm  =  LOOKUP  DSMLocation 

/*  Obtain  an  authenticated  paeket  by  eontaeting  the  DSM.  Pass  the  authentication 
information  (userType,  userName,  password,  contactLocation  ,  domain)  to  the 
DSM  and  wait  for  response  */ 
authenticatedPacket  = 

CALL  DSM_AUTHENTICATION  SERVICE  ol dsm  with 
userType,  userName,  password,  contactLocation,  domain 
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//Extract  multicast  address  and  secret-key  from  authentieatedPaeket. 
multicastAddress  =  GET  multicast  Address  from  authentieatedPaeket 
secretKey  =  GET  secretKey  from  authentieatedPaeket 
H  Onee  multieast  address  is  obtained  join  the  multieast  group. 

JOIN  multieast  group  with  multicastAddress 
START  AR_RECEIVE_MULTICAST_COMMUNICA  TION 
ACTIVATE  ARGETjCOMPONENTDATA 
END  AR  INITIALIZATION 


4.8. 1 .2  Algorithm  for  AR  Reeeiving  Multieast  Communieation 

This  algorithm  outlines  the  proeess  in  whieh  an  AR  reeeives  multicast  communication 
from  the  Headhunters.  On  reeeiving  the  Headhunter  multieast  messages  with  its  loeation 
information  the  AR  deerypts  the  message  using  the  seeret-key  and  unieasts  it’s  enerypted 
eontaet  loeation  to  the  Headhunter. 

ARRECEIVEMULTICASTCOMMUNICATION 
IN:  encryptedPfeadhunterLocation 
WHILE  TRUE 

IE  eontaeted  by  Headhunter  with  encryptedPfeadhunterLocation 

/*  Reeeive  enerypted  Headhunter  loeation  information  multieast  to 
registry  by  Headhunters.  Deerypt  the  loeation  information  using 
seeret-key.  */ 

HeadhunterLocation  = 

secretKey  {encryptedPfeadhunterLocation} 

//Get  a  handle  to  the  headunter  running  at  the  loeation 
Headhunter  =  LOOKUP  HeadhunterLocation 
CALL  HH  RECEIVE _UNICAST_  COMMUNICATION  on 

Headhunter  with  vegistryLocation 
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ENDIF 
END  WHILE 

END  AR  RECEIVE  MULTICAST  COMMUNICATION 


4. 8. 1. 3  Algorithm  for  Obtaining  UniFrame  Specifications  of  Registered  Components 

This  algorithm  outlines  the  process  for  obtaining  the  UniFrame  specifications  of 
the  components  registered  with  an  AR.  The  AR  gets  a  URL  list  of  all  the  components 
registered  with  it.  It  then  steps  through  this  list  and  gets  a  handle  to  each  of  these 
components.  Using  the  component  reference,  the  AR  examines  the  component’s 
properties  to  check  for  a  property  returning  the  URL  of  its  UniFrame  specification.  The 
AR  then  reads  the  XML-based  UniFrame  specification  from  the  URL  and  parses  this 
specification  to  obtain  all  the  component  details,  which  it  stores  in  an  entity  object 
componentEntity.  The  AR  builds  a  hash  table  of  such  entities  corresponding  to  each  of 
the  components  registered  with  it  and  returns  this  hash  table  to  the  Headhunter. 

ARGETCOMPONENTDATA 
OUT:  componentTable 
WHILE  TRUE 

IF  contacted  by  HH  to  retrieve  component  data 
CREATE  a  new  componentTable 

//Obtain  a  list  of  object  URL’s  of  all  objects  registered  with  this 
//  registry. 

registeredServicesURLList  =  GET  LIST  of  service  components 

registered  with  this  Active  Registry 
//  For  each  object  in  this  URL  list 
FOR  i=0  to  LENGTH  of  registeredServicesURLList 

registeredServiceURL  =  registeredServicesURLList [i] 

H  Lookup  and  obtain  the  reference  to  the  services  from  the 
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//  registry  using  the  registered  serviee  URL. 
serviceObject  =  LOOKUP  registeredServiceURL 
1 1  Obtain  the  loeation  (URL)  of  the  UniFrame  Specifieation 
//  for  this  serviee  by  introspecting  its  property  name  called 
//  “uniFrame Specification 
uniFrameSpecURL  = 

CALL  ARJNTROSPECT  PROPERTY  with 

serviceObject,  “uniFrameSpecification  ” 

H  Parse  the  UniFrame  Specification  and  construct  a 
//  componentEntity  which  can  be  persisted. 

CREATE  a  componentEntity 
document  =  PARSE  uri  and  load  XML  document 
CALL  AR  PARSEJJNIFRAME  SPEC  with  document 
//Add  the  component  to  the  componentTable 
PUT  <  registeredServiceURL,  componentEntity> 
in  componentTable 
ENDFOR 

RETURN  componentTable 

ENDIF 
END  WHILE 

END  AR  GET  COMPONENT  DATA 


4. 8. 1.4  Algorithm  for  Parsing  the  UniFrame  Specification 

This  algorithm  uses  recursion  to  parse  through  the  nodes  of  the  XME  tree,  extract  the 
node  values  and  store  these  values  in  the  componentEntity.  The  algorithm  starts  parsing  at 
the  root  node  element.  It  extracts  the  node  name  and  checks  if  the  node  name  matches 
any  attribute  in  componentEntity  and  populates  it  with  the  value  in  this  node.  It  then  finds 
all  the  children  of  that  node  and  repeats  the  process  through  recursion. 
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ARPARSEUNIFRAMESPEC 
IN:  nodeElement 

nodeName  =  GET  NODE  NAME  from  nodeElement 
EOR  each  attribute  in  componentEntity 
IE  nodeName  EQUAES  attribute 
nodeValue  =  GET  NODE  VAEUE  from  nodeElement 

SET  attribute  value  in  componentEntity  to  nodeValue 

ENDIF 

ENDFOR 

//  Get  the  list  of  children  for  this  Node. 

NODEEIST  childrenList  =  GET  CHIEDNODES  for  nodeElement 
IF  childrenList  NOT  NULE 

//  For  every  child  node  in  the  list 
FOR  i  =  0  to  EENGTH  of  childrenList 
childNode  =  childrenList [i] 

H  Recurse  through  the  function  READ  NODE  passing  it  the 
//  childNode  as  reference. 

GALE  ARP  ARSE  UNIERAME  SPEC  with  childNode 
ENDFOR 

ENDIF 

END  AR  PARSE  UNIFRAME  SPEC 


4. 8. 1.5  Algorithm  for  Introspection  of  the  Registered  Components 

This  algorithm  outlines  the  process  for  examining  a  service  object  to  find  a  specific 
property  and  retrieve  its  value.  The  algorithm  gets  a  list  of  all  the  properties  from  the 
service  object  and  tries  to  find  a  match  for  the  specific  property  of  interest.  Once  the 
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property  is  found,  a  handle  to  the  Read  aceessor  method  (getter)  of  this  property  is 
obtained  and  invoked. 

ARINTROSPECTPROPERTY 

IN:  serviceObject,  propertyName 
OUT:  property 

//Introspeet  and  retrieve  all  information  pertaining  to  this  serviee  objeet. 
serviceObjectInfo  =  INTROSPECT  serviceObject  to  retrieve  objeet  information 
//Get  a  deseription  list  of  all  properties  of  this  objeet. 
propertyDescriptorList  = 

GET  PROPERTY  DESCRIPTORS  from  serviceObjectInfo 
//Iterate  through  the  deseription  list  to  find  the  desired  property. 

EOR  i=0  to  EENGTH  of  propertyDescriptorList 

propertyDescriptor  =  propertyDescriptorListji] 
propertyDescriptorName  =  GET  NAME  of  propertyDescriptor 
//If  the  property  deseriptor  name  matehes  the  desired  property  name 
IE  propertyDescriptorName  EQUAES  propertyName 

//Get  the  aeeessor  method  that  returns  the  property  value. 
method  =  GET  READ  METHOD  of  propertyDescriptor 
//Invoke  the  method  to  retrieve  the  value. 
property  =  INVOKE  method  of  serviceObject 
//Return  this  property  to  the  requester. 

RETURN  property 

ENDIE 

ENDEOR 


END  AR  INTROSPECT  PROPERTY 
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4.9  Services 


Service  Exporter  Components  are  implemented  in  different  models,  e.g.,  Java 
RMI,  CORBA,  EJB,  etc.  The  components  are  identified  by  their  Service  Offers 
comprising  of  service  type  name,  b)  informal  UniErame  specification,  and  c)  zero  or 
more  QoS  values  for  that  service.  A  component  registers  its  interfaces  with  an  Active 
Registry.  The  component  interface  contains  a  method,  which  returns  the  URL  of  its 
informal  specification.  The  informal  specification  is  stored  as  an  XML  file  adhering  to 
certain  syntactic  contracts  to  facilitate  parsing.  These  service  exporter  components  will  be 
tailored  for  specific  domains  such  as  Einancial  Services,  Health  Care  Services, 
Manufacturing  Services,  etc.,  and  will  adhere  to  the  relevant  standards,  business 
architectures,  and  research  and  technologies  for  these  industry  specific  markets. 


This  chapter  presented  the  high-level  design  for  the  components  in  the  URDS 
architecture.  The  next  chapter  presents  a  prototype  implementation  for  the  URDS 
architecture. 
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5.  IMPLEMENTATION  OE  THE  URDS  ARCHITECTURE 

Chapter  4  provided  a  conceptual  perspective  of  the  URDS  architecture.  The 
architecture  presented  did  not  adhere  to  any  specific  implementation  methodology.  The 
URDS  architecture  can  be  realized  using  several  different  software/hardware 
technologies.  This  chapter  describes  a  prototype  implementation  for  the  URDS 
architecture  using  Java  and  Java  based  technologies. 

The  chapter  is  organized  as  follows:  Section  5.1  presents  technological  artifacts 
and  architectural  models,  which  were  used  in  the  prototype  implementation.  Section  5.2 
presents  the  prototype  implementation  followed  by  experimental  results  from  the 
prototype  in  Section  5.3.  Section  5.4  outlines  implementation  strategies  that  can  be  used 
to  enhance  the  prototype  implementation. 


5.1  Technology 

This  section  describes  various  architectural  artifacts  and  technologies  that  have 
been  leveraged  in  the  implementation  the  URDS  architecture. 


5.1.1  Web  Servers  and  Application  Servers 

A  Web  Server  consists  of  computer  hardware  and  software  programs  that  serve  up 
static  content  like  HTML  pages,  images  and  documents  to  remote  browsers  accessing  the 
web  server.  Web  Servers  are  assigned  IP  addresses  using  which  remote  applications  can 
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access  it  using  the  HTTP  protoeol.  Web  Servers  are  also  called  HTTP  servers.  Examples 
for  Web  Servers  include  the  IBM  Http  Server  [IBMa],  iPlanet  Web  Server  Enterprise 
Edition  [IPE],  and  Apaehe  Http  Server  [APA], 

Application  Servers  are  software  eomponents  that  eollaborate  with  Web  Servers 
to  return  eustomized  results  (dynamie  eontent)  to  a  elient’s  request.  Examples  of 
Applieation  servers  inelude  IBM  WebSphere  Applieation  Server  [IBMb],  WebEogic 
[BEA],  and  IIS  [MIC].  Eigure  5.1  illustrates  the  relationship  between  Browsers/Clients, 
Web  Servers  and  Applieation  Server.  The  browser  clients  eommunicate  with  the  web 
servers  using  HTTP  protoeol.  The  web  servers  in  turn  eommunicate  with  the  applieation 
servers  to  retrieve  dynamic  content,  whieh  is  returned  to  the  elients.  The  applieation 
servers  eommunicate  with  back-end  database  systems/directory  servers  using  standard 
eommunieation  protoeols. 


Eigure  5.1.  Interaetion  between  Clients,  Web  Servers  and  Applieation  Servers. 


5.1.2  Java™  2  Platform  Enterprise  Edition  (J2EE™) 

The  prototype  implementation  is  based  on  the  arehitectural  model  laid  out  by 
[SUNOlb]  in  J2EE™.  J2EE™  defines  a  standard  that  applies  to  all  aspeets  of 
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architecting,  developing,  and  deploying  multi-tier,  server-based  applications.  Figure  5.2 
[SUNOlb]  shows  the  components  of  the  J2EE  Model. 


Eigure  5.2.  Components  and  Containers  of  J2EE  Model. 
(Eigure  5.2  is  courtesy  SUN  Microsystems,  [SUNa]) 


The  J2EE™  platform  specifies  technologies  to  support  multi-tier  enterprise 
applications.  These  technologies  fall  into  three  categories  [SUNOlb]:  Component, 
Service,  and  Communication.  The  following  sub-sections  outline  the  technologies  (see 
Eigure  5.2)  in  each  of  these  categories  that  have  been  used  in  the  implementation.  (The 
Java  based  technologies  described  in  these  sections  are  proprietary  technologies  of  SUN 
Microsystems  [SUNOlb]). 


5. 1.2.1  Component  Technologies 


Components  are  application-level  software  units.  All  J2EE  components  depend  on 
the  runtime  support  of  a  system- level  entity  called  a  "''Container” .  Containers  provide 
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components  with  services  sueh  as  life  eycle  management,  seeurity,  deployment,  and 
threading. 

The  J2EE  Component  technologies  have  been  used  in  the  prototype  to  ereate  the 
front-end  elient  eomponents  and  back-end  service  eomponents.  The  prototype  supports 
two  types  of  clients:  Application  Clients  whieh  are  structured  as  Application  Client 
Components  (deseribed  in  seetion  5. 1.2. 1.1)  and  Web  Clients,  whieh  interaet  with  the 
Web  Components  (deseribed  in  seetion  5. 1.2. 1.2).  The  prototype  also  uses  the  JavaBean 
Components  (deseribed  in  seetion  5. 1.2. 1.3)  in  the  elient  and  server  tiers  of  the 
implementation. 

The  different  types  of  J2EE  eomponents  used  in  the  prototype  are  described 

below: 

5. 1.2. 1.1  Application  Client  Components 

Application  clients  are  client  eomponents  that  exeeute  in  their  own  Java  virtual 
maehine.  Application  clients  are  hosted  in  a  Application  Client  Container. 

5. 1.2. 1.2  Web  Components 

A  Web  Component  is  a  software  entity  that  provides  a  response  to  a  request.  The 
J2EE  platform  specifies  two  types  of  Web  eomponents:  Servlets  and  JavaServer  Pages™ 
(JSP)  pages.  A  Web  Container  hosts  web  eomponents. 

•  Java  Servlet  Technology  2.3:  Servlets  extend  the  eapabilities  of  web  servers  that 
host  applieations  aeeessed  by  way  of  a  request-response  programming  model. 
Java  Servlet  teehnology  has  provisions  for  defining  HTTP-speeifie  servlet  elasses. 
Although  servlets  ean  respond  to  any  type  of  request,  they  are  eommonly  used  to 
extend  the  applieations  hosted  by  Web  servers. 

•  JavaServer  Pages  Technology  1.2:  The  JavaServer  Pages  (JSP)  teehnology 
provides  an  extensible  way  to  generate  dynamie  content  for  a  Web  elient.  A  JSP 
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page  is  a  text-based  doeument  that  deseribes  how  to  proeess  a  request  to  ereate  a 
response.  It  eontains  two  types  of  text:  static  template  data,  which  can  be 
expressed  in  any  text-based  format  such  as  HTML,  WML,  and  XML,  and  JSP 
elements  (snippets  of  servlet  code),  which  determine  how  the  page  constructs 
dynamic  content. 

5. 1.2. 1.3  JavaBean  and  Enterprise  JavaBean  Components 

A  JavaBean  Component  is  a  body  of  code  with  fields  and  methods  to  implement 
modules  of  business  logic.  The  server  and  client  tiers  can  include  components  based  on 
the  JavaBeans  component  architecture.  Enterprise  JavaBeans  are  server-side  components 
that  encapsulate  the  business  logic  of  an  application  and  support  enterprise  level 
processing  by  making  the  JavaBeans  scalable,  transactional,  and  multi-user  secure.  An 
EJB  container  hosts  Enterprise  beans. 


5. 1.2.2  Service  Technologies 

The  J2EE  platform  service  technologies  allow  applications  to  access  a  variety  of 
services.  The  prominent  service  technologies  supported  are  JDBC™  API  2.0  which 
provides  access  to  databases,  Java  Transaction  API  (JTA)  1.0  for  transaction  processing, 
Java  Naming  and  Directory  Interface  (JNDI)  1.2  which  provides  access  to  naming  and 
directory  services,  and  J2EE  Connector  Architecture  I.O  which  supports  access  to 
enterprise  information  systems. 

The  service  technologies  used  in  the  prototype  are  described  below: 

•  JDBC™  API  2.0:  The  JDBC™  API  provides  methods  to  invoke  SQE  commands 
from  Java  programming  language  methods.  The  JDBC  API  has  two  parts:  an 
application-level  interface  used  by  the  application  components  to  access  a 
database,  and  a  service  provider  interface  to  attach  a  JDBC  driver  to  the  J2EE 
platform. 
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•  Java  API  for  XML  Processing  1.1:  XML  is  a  language  for  representing  text-based 
data  so  the  data  can  be  read  and  handled  by  any  program  or  tool.  Programs  and 
tools  can  generate  XML  documents  that  other  programs  and  tools  can  read  and 
handle.  Java  API  for  XML  Processing  (JAXP)  supports  processing  of  XML 
documents  using  DOM,  SAX,  and  XSLT  parsers.  JAXP  enables  applications  to 
parse  and  transform  XML  documents  independent  of  a  particular  XML  processing 
implementation. 


5. 1.2. 3  Communication  Technologies 

Communication  technologies  provide  mechanisms  for  communication  between 
clients  and  servers  and  between  collaborating  objects  hosted  by  different  servers.  Some 
of  the  communications  technologies  supported  by  the  J2EE  Platform  include  -  Transport 
Control  Protocol  over  Internet  Protocol  (TCP/IP),  Hypertext  Transfer  Protocol  HTTP  1.0, 
Secure  Socket  Eayer  SSE  3.0,  Java  Remote  Method  Protocol  (JRMP),  Java  IDE,  Remote 
Method  Invocation  over  Internet  Inter  ORB  Protocol  (RMI-IIOP),  Java  Message  Service 
1.0  (JMS),  JavaMail  and  Java  Activation  Eramework. 

The  prototype  uses  the  HTTP  1.0  Protocol  for  communication  between  the 
browser-based  clients  and  server  side  components.  The  inter-component  communication 
on  the  server  side  is  achieved  through  Java  Remote  Method  Invocation. 

The  protocols  used  in  the  prototype  are  described  below. 

•  HTTP  1.0  Protocol:  The  Hypertext  Transfer  Protocol  (HTTP)  is  an  application-level, 
generic  stateless  protocol  for  distributed,  collaborative,  hypermedia  information 
systems. 

•  Java  Remote  Method  Protocol  (JRMP):  Remote  Method  Invocation  (RMI)  is  a  set  of 
APIs  in  the  Java  programming  language  that  enables  developers  to  build  distributed 
applications.  RMI  uses  Java  language  interfaces  to  define  remote  objects  and  a 
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combination  of  Java  serialization  technology  and  the  Java  Remote  Method  Protocol 
(JRMP)  for  performing  remote  method  invocations. 


5 .2  Prototype  Implementation 


This  section  describes  an  implementation  of  a  prototype  for  the  URDS 
architecture  described  in  Chapter  4.  Figure  5.3  illustrates  this  implementation.  The 
architecture  is  implemented  as  a  multi-tier,  distributed  application  model,  which  means 


Figure  5.3.  URDS  Implementation 
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that  the  various  parts  of  the  prototype  implementation  can  run  on  different  machines.  This 
is  in  conformance  with  the  J2EE  architecture,  which  defines  a  client  tier,  a  middle  tier 
(consisting  of  one  or  more  sub  tiers),  and  a  backend  tier  providing  services  of  enterprise 
information  systems.  In  the  prototype,  the  client  tier  supports  a  variety  of  client  types, 
both  application  clients  as  well  as  web-based  clients.  The  middle  tier  supports  client 
services  through  Web  containers  in  the  Web  tier.  The  middle  tier  also  supports  the 
component  services  (DSM,  QM,  EM,  HH,  AR  which  form  the  core  of  the  EIRDS 
architecture)  as  Java-RMI  based  services.  The  Database  tier  supports  access  to  the 
repositories  by  means  of  standard  APIs. 


5.2.1  Platform  and  Environment 

In  the  prototype,  the  algorithms  outlined  for  the  various  components  are 
implemented  using  the  Java™  2  Platform,  Standard  Edition  (J2SE)  [SUNb]  version  1.4 
software  environment.  The  core  architectural  components  (DSM,  QM,  EM,  HH,  and  AR) 
are  implemented  as  Java-RMI  based  services.  The  repositories  (DSM  Repository  and 
Meta  Repositories)  are  database-oriented  implementations  based  on  Oracle  v  8.0.  The 
web-based  components  (JSPs),  which  service  client  interactions,  are  housed  in  the 
Tomcat  4.0  Servlet/JSP  Container. 


5.2.2  Communication  Infrastructure 

The  unicast  communication  between  the  core  architectural  components  is  based 
on  JRMP.  The  multicast  communication  between  HHs  and  ARs  is  achieved  through 
Multicast  Sockets  based  on  UDP/IP.  The  connections  to  the  databases  are  established 
using  JDBC  APIs.  Interactions  between  the  clients  (users)  and  the  web  components  are 
based  on  HTTP  protocol. 
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5.2.3  Security  Infrastructure 

The  security  infrastructure  in  the  URDS  utilizes  the  security  and  cryptography 
APIs  that  form  a  part  of  the  Java^'^  Cryptography  Architecture  (JCA)  [SUN02]  and 
Java™  Cryptography  Extension  (JCE)  frameworks  [SUNOO].  The  specifications  outlined 
in  the  JCA  encompass  the  parts  of  the  Java  2  SDK  Security  API  related  to  cryptography. 
The  JCE  provides  a  framework  and  implementations  for  encryption,  key  generation  and 
key  agreement,  and  Message  Authentication  Code  (MAC)  algorithms.  The  JCA  and  JCE 
frameworks  are  based  on  the  concepts  of  “engine  classes”  and  a  “provider”  architecture. 
An  engine  class  defines  a  cryptographic  service  in  an  abstract  fashion  (without  a  concrete 
implementation).  The  actual  implementations  (from  one  or  more  providers)  are  those  for 
specific  algorithms.  A  “provider”  refers  to  a  package  or  set  of  packages  that  implement 
one  or  more  cryptographic  services,  such  as  digital  signature  algorithms,  message  digest 
algorithms,  and  key  generation  algorithms.  The  JCE  Provider  used  in  the  prototype  is  the 
“SunJCE”[SUN00]  which  comes  as  a  pre-installed  and  registered  standard  JCE  Provider 
with  the  Java  2  SDK,  v  1 .4  release. 

5.2.4  Programming  Model 

In  the  implementation  of  the  prototype,  the  URDS  functionality  is  partitioned  into 
modules,  and  these  modules  are  decomposed  into  specific  objects  to  represent  the 
behavior  and  data  of  the  application.  The  prototype  adapts  the  Model-View-Controller 
(MVC)  architecture.  The  MVC  architecture  [GAM95,  YOU95]  can  be  described  as: 
“The  Model  represents  the  application  data  and  the  rules  that  govern  access  and 
modification  of  this  data.  The  View  renders  the  contents  of  a  model.  It  accesses  data  from 
the  model  and  defines  how  that  data  should  be  presented.  The  Controller  defines 
application  behavior;  it  translates  user  gestures  into  actions  to  be  performed  by  the 
model”. 
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5.2.4.1  Implementation  Details 

In  order  to  structure  an  application  along  the  lines  of  the  MVC  architecture  it  is 
necessary  to  divide  the  application  into  objects  and  assign  these  objects  to  tiers.  This 
process  is  referred  to  as  object  decomposition.  Typically  an  application  can  be  divided 
into  three  logical  categories  of  objects:  “These  are  objects  that  deal  with  presentation 
aspects  of  the  application,  objects  that  deal  with  the  application  rules  and  data,  and 
objects  that  accept  and  interpret  user  requests  and  control  the  application  objects  to 
fulfill  these  request”  [SUNa]. 

Following  sections  outline  the  object  decomposition  in  the  prototype  along  the 
lines  of  the  MVC  architecture  and  explain  the  functionality  served  by  each  of  these 
objects  in  the  prototype. 

5. 2.4. 1.1  The  Model 

This  section  explains  the  subdivision  of  components  in  the  “Model”  segment  of 
the  architecture.  The  components  in  this  segment  have  been  categorized  as:  Entity 
Objects,  Helper  Objects,  Persistent  Data,  and  the  Component  Services  depending  on  their 
functionality. 

5.2. 4. 1.1.1  Entity  Objects 

Entity  objects  serve  to  represent  the  individual  rows  in  a  database  as  objects  or  to 
encapsulate  an  application  specific  concept  in  terms  of  an  object.  The  entity  objects  in  the 
prototype  support  accessor  methods  to  set  and  retrieve  the  values  of  the  attributes  they 
hold.  These  objects  can  be  passed  by  value  as  serializable  Java  objects.  The  prototype 
contains  the  following  entity  objects  ComponentBean,  FunctionBean,  QueryBean, 
AuthenticatedPacket  whose  class  diagrams  are  illustrated  in  Eigure  5.4. 
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AuthenticatedP  ack  et 


^‘SjuthenticatedP  ack  etQ 
%etKeyO 
^etMC  AddressO 
CAddressO 
%etKeyO 


FunctionBean 


^unctionBeanO 

^uildBeanQ 
getFunctionNan  eQ 
JgetSvntacti  oC  ontractO 
^etFunct  ionN  am  eO 
JsetSvntactioC  ontractO 
getldO 
^IdO 
persistBeanO 


_ ComponentBean 

ttend2endDelay ;  double  =  0 
Availability:  double  =  0 

^om  ponentB  eanO 
JddFunctionBeansO 
XuildBeanO 
JetAgorithmO 
^etAvailabilityO 
^etComple>jtyO 

^etDescri  ption  0 

^etDomainO 

^etE  nd2endD  elayO 

^etFunctionO 
^etFunctionBeanListO 
igetldO 
^getMobilityO 
<getNameO 
aetP  reprocessingC  oil  aborators(  i 
SetStatusO 
aetT  echnologyO 
J^Agorithm  0 
setAvailabilityO 
^etCom  ple>dtvO 
^etDescriptionO 
setDomainO 
^etE  nd2endD  elayO 
setFunctionO 
^etFunctionBeanLi  stO 
setIdO 

%etMobilitvO 
^^Nam  eO 
setP  reprocess!  ngCol  laboratorsC 
%etStatusO 
setT  echnologyO 
%etUpdateSttingO 
persistBeanO 


_ QueryBean _ 

AavailabilityFlag  :  boolean  =  false 

yavailabilityyalue  :  double  =  0 
yend2endDelayFlag  :  boolean  =  falsf 
yend2endDelayValue  :  double  =  0 
nu«n  Offers  :  int  =  0 
^nun  Metrics :  int  =  0 
^hopcount :  int 


QueryBeanO 
^get  Agorithm  QueryO 
*  get  Aval  labil  ityQ  uer^ 

^getCom  pi  exityQ  ueryO 
•^getCom  ponentD  escriptionQueryO 
^getCom  ponentN  am  eQueryO 
^getDomainO 
getE  nd2E  ndD  elayQ  ueryO 
^getFundi  onN  am  esQueryO 
getMobi  lityQueryO 
JgetT  echnologyQ  ueryO 
setAgorithmsO 
^setAvailabilityConstraintO 
^set  Availabi  lity  Flag  0 
set  Avallabi  lityValueO 
^setCcm  plexityO 
setCom  ponentDescriptionO 
^setCom  ponentNameO 
setDomainO 

^setE  nd2endDelayC  onstraintC) 
^setE  nd2endD  elayF  lagO 
setE  nd2endD  elayValue() 

^set  FunctionN  am  esO 
setMobilityO 
%setNcm  MetricsO 
^setNcm  OffersQ 
setT  echnologyO 
♦tokeniseStringO 
getQueiyO 
♦getHopcountO 
getRequestIDO 
%setHopcountO 
setRequestIDO 


Figure  5.4.  Class  Diagrams  for  the  URDS  Entity  Objects 


Following  is  an  explanation  of  these  entity  objects. 


ComponentBean:  The  attributes  of  the  ComponentBean  class  mirror  the  fields  of  the 
table  Component  (see  Section  5. 2.4. 1.1. 3).  The  ComponentBean  internally  holds  a  list  of 
FunctionBean  objects.  The  ComponentBean  has  functionality  built  in  to  persist  it  to  a 
database. 


FunctionBean:  The  attributes  of  the  FunctionBean  mirror  the  fields  of  the  table  Function 
(see  Section  5. 2.4. 1.1. 3).  The  FunctionBean  has  functionality  built  in  to  persist  it  to  a 
database. 


QueryBean:  The  QueryBean  encapsulates  the  attributes  of  a  Query  received  from  the 
client.  The  bean  also  has  the  logic  associated  with  generating  a  SQL  query  based  on  the 
attributes  it  holds. 
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AuthenticatedPacket:  The  AuthenticatedPacket  encapsulates  the  multicast  address  and 
secret-key  returned  to  the  principals  (Headhunters/ActiveRegistries)  by  the  Domain 
Security  Manager. 

5. 2. 4. 1.1. 2  Helper  Objects 

The  prototype  uses  Helper  objects  for  purposes  such  as  data  access  or  for 
performing  specific  utility  functions.  The  following  classes  serve  as  Helper  classes  and 
have  been  sub-classified  under  the  categories  of  Data  Access  Objects  and  Dependent 
Objects. 


5. 2. 4. 1.1. 2.1  Data  Access  Objects 


The  data  access  objects  used  in  the  prototype  encapsulate  access  to  databases. 


DSM  Repos!  to  ryHelper 


•^initialize  () 

•1b  uth  e  nti  c  ate  U  se  r  () 
^getFeaturesFromResultS. 
■%o  adDomai  nList() 
•lioadUserDomainMappingO 
■teetLIstOfOomalnsfl 


- > 

-$sqlHelper 


SQLHelper 


•16QLHelper() 

•Ieo  mmitTransactio ... 
•^execute  Query  () 
•IgetDbconnO 
•<0  etState  me  nt  () 

•*n  ItiateTransaction  () 

.^follbackTransacti ... 

.^etObconnO 

•lee  tSta  te  me  n  t( ) 

.^hutDownO 

.^pdateTableO 


Meta  RepositoryHelper 


^MetaRepositoryHelp  . 
.^etSea  rchResuItT  abl . . 
^MetaRepositoryHelp .. 


Figure  5.5.  Class  Diagrams  for  the  Data  Access  Objects 
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Figure  5.5  illustrates  the  elass  diagrams  of  the  data  aeeess  objeets.  A  deseription  of  the 
data  aeeess  objects  used  in  the  prototype  is  provided  here: 

DSMRepositoryHelper:  This  class  performs  functions  associated  with  accessing  the 
DSM  Repository  to  retrieve  user-domain  mappings  and  for  user  authentication. 

MetaRepositoryHelper:  This  class  performs  functions  associated  with  accessing  the 
Meta_Repository  to  retrieve  search  results. 

SQLEngine:  This  class  acts  as  a  wrapper,  which  encapsulates  the  essential,  JDBC  API 
methods  and  performs  functions  associated  with  establishing  database  connections  and 
executing  the  queries.  It  is  used  by  the  DSMRepositoryHelper  and  MetaRepositoryHelper 
classes. 

5. 2. 4. 1.1. 2. 2  Dependent  Objects 

The  prototype  uses  dependent  objects  for  performing  utility  functions.  These 
dependent  objects  are  immutable  and  the  objects  that  create  and  use  them  manage  their 
life  cycle. 

Figure  5.6  illustrates  the  class  diagrams  of  the  dependent  objects.  A  description  of  the 
dependent  objects  is  provided  below: 

CreateKey:  This  utility  class  is  used  to  generate  secret-keys.  The  keys  are  generated 
using  a  SUN  provided  engine  class  javax.crypto.KeyGenerator,  which  provides  the 
functionality  of  a  (symmetric)  key  generator.  An  instance  of  the 
javax.crypto.KeyGenerator  class  is  obtained  by  specifying  the  Provider  and  the  algorithm 
for  key  generation.  The  Provider  used  is  the  “SunJCE”  an  instance  of  which  can  be 
obtained  by  instantiating  the  com. sun.crypto.provider. SunJCE  class.  The  algorithm 
specified  is  “DES”  (Data  Encryption  Standard)  [DES77]. 
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-crypto  bject 


.  MulticastReceiver 


port :  int  =  1 0000 

♦runO 
MulticastReceiver( 


-objSerializer 


-objSerializ^ 


ObjectSerializer 


^ObJectSerializ.. 

▼ObjectSerializ.. 

tObjectSerializ.. 

getObjectO 
^setObjectO 
'getBytesO 
■  setBytesQ - 


rf'port :  int  =  10000 
gtti  :  byte  =  (byte)  1 
Sbufferll :  byte 
^TPmcast :  long 

- 

^runQ 

MulticastSenderO 


Ore  ate  Key 


^ - 

4  Ore  ate  K.. 
getKeyO 


UniFrarreSpecificationParser 

CryptObj 

k  populatedFlag  :  boolean  =  fa. . 

%n  Crypto .. 

'  UnlFrameSpecificatlonParser) 

Jde  Crypto .. 

2  getComponentBeanO 

■•CryptObjO 

^  -crypto  bject 

w  readNodeO 

RequestProcessor 


*RequestProcess.. 

^clearResultsO 

^getResuItT  ableQ 

^setResuItTableO 

^getQueryBeanO 

^setQueivBeanO 


UniFrameIntrospector 


«  UniFrameIntrospect.. 
getPropertyO 


Un  i  F  ra  me  I  nt  rosp  ectorExceptlon 


^  UniFran^IntrospectorException) 
UniFrameIntrospectorException) 


Figure  5.6.  Class  Diagrams  for  the  Dependent  Objects 


CryptObj:  This  class  provides  the  utility  functions  for  encrypting  and  decrypting  data. 
The  class  utilizes  a  SUN  provided  engine  class  javax.crypto. Cipher,  which  is  capable  of 
carrying  out  encryption  and  decryption  according  to  an  encryption  scheme  (algorithm). 
An  instance  of  the  Cipher  class  can  be  obtained  by  specifying  a  transformation  of  the 
form  "algorithm/mode/padding” .  The  transformation  used  in  the  prototype  is 
"DES/ECB/PKCS 5 Padding”  where  algorithm  =  “DES”,  mode  =  “ECB”  (Electronic 
Codebook  Mode)  [ECB80]  and  padding  =  ''PKCS 5 Padding”  (The  Public  Key 
Cryptography  Standards  #5)[RSA93].  Modes  and  padding  schemes  are  present  in  the 
Cipher  class  because  that  class  implements  what  is  known  as  a  block  cipher;  that  is,  it 
expects  to  operate  on  data  one  block  (e.g.,  8  bytes)  at  a  time.  Padding  schemes  are 
required  in  order  to  ensure  that  the  length  of  the  data  is  an  integral  number  of  blocks. 
Modes  are  provided  to  further  alter  the  encrypted  data  in  an  attempt  to  make  it  harder  to 
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break  the  eneryption.  The  CryptObj  elass  enerypts  an  objeet  with  a  eryptographie 
algorithm  to  ereate  an  instanee  of  javax.crypto.SealedObject. 

ObjectSerializer:  This  utility  elass  eonverts  an  objeet  to  byte  array  and  reeonstruets  an 
objeet  from  byte  array.  To  be  used  in  seeure  multieast  for  serializing  Sealed  Objeets. 

UniFrameIntrospector:  This  utility  elass  uses  refleetion  to  analyze  the  properties  of  an 
objeet  and  retrieve  the  value  eorresponding  to  a  speeifie  attribute. 

UniFrameSpecificationParser:  This  elass  is  used  to  parse  a  UniFrame  XML 
speeifieation  file  and  eonstruet  an  instanee  of  the  ComponentBean. 

MulticastSender:  This  elass  operates  as  a  Thread  whieh  exeeutes  periodieally.  This 
Thread  has  a  eonneetion  to  a  MulticastSocket  to  whieh  it  keeps  multieasting 
DatagramPackets  at  regular  intervals  of  time.  This  thread  utilizes  the  CryptObj ect  and 
ObjectSerializer  Helper  objeets  to  multieast  enerypted  serialized  messages. 

MulticastReceiver:  This  elass  operates  on  a  Thread,  whieh  eonstantly  listens  for 
multieast  messages  on  a  MulticastSocket  and  reeeives  the  ineoming  DatagramPackets. 
This  thread  utilizes  the  CryptObj  ect  and  ObjectSerializer  Helper  objeets  to  deerypt  and 
reeonstruet  the  multieast  messages  reeeived. 

5. 2.4. 1.1. 3  Persistent  Data 

The  prototype  maintains  persistent  data  in  database  tables.  These  databases  are 
assoeiated  with  the  serviee  eomponents  (i.e.  DSM  and  HH).  The  databases  used  in  the 
prototype  are  the  DSM  Repository  and  the  Meta_Repository. 
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DSMRepository 


Figure  5.7  illustrates  the  schema  for  the  DSM  Repository . 


Figure  5.7.  DSM  Repository 


The  DSM_Repository  comprises  of  four  tables  Users,  Permissions, 
User_Permission_Xref,  and  DomainList. 

The  Users  table  serves  to  hold  the  Headhunter/ ActiveRegistry  information.  The 
columns  of  this  table  are  userid  (numeric  identifier),  usertype  (whether  Headhunter  or 
Registry),  username,  and  password.  The  primary-key  in  this  table  is  the  userid.  Example 
of  a  record  of  this  table  is  as  follows:  <!,’ Headhunter’,  ‘Headhunterl’,  ‘xxxx’>. 

The  Permissions  table  serves  to  hold  a  list  of  allowed  permissions  (or  domains). 
The  columns  in  this  table  are  permissionid  (numeric  id  for  permission)  and 
permissionname  (domain  name  like  Finance,  Manufacturing,  etc.,).  The  permissionid 
serves  as  the  primary-key  for  this  table.  Example  of  a  record  of  this  table  is  as  follows: 
<1,  ‘Manufacturing’>. 
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The  User_Permission_Xref  table  serves  to  map  the  permission  to  be  assigned  to  a 
user.  The  table  eontains  two  numerie  eolumns  userid  whieh  referenees  the  userid  in 
Users  and  permissionid  whieh  referenees  permissionid  in  Permissions .  The  eombination 
of  the  <userid,permissionid>  serve  as  the  primary  key.  Example  of  a  reeord  of  this  table 
is  as  follows:  <1,  2>. 


The  DomainList  table  serves  to  hold  the  list  of  multieast  addresses  and  the 
domains  that  they  map  to.  The  table  eontains  two  columns  domainid,  which  references 
permissionid  of  Permissions  and  domainaddress,  which  serves  to  hold  the  multicast 
address.  The  combination  of  the  <  domainid,  domainaddress  >  serve  as  the  primary  key. 
Example  of  a  record  of  this  table  is  as  follows:  <1,  ‘224.2. 2.2’>. 


MetaRepository 


Eigure  5.8  illustrates  the  schema  for  the  Meta_Repository. 
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Eigure  5.8.  Meta_Repository 
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The  Meta_Repository  comprises  of  two  tables  Component,  Function. 

The  Component  table  serves  to  hold  the  UniFrame  Specification  information  of 
the  components.  The  columns  of  this  table  are  id  (alpha  numeric  compinent  id),  and  other 
variables  which  describe  a  component  like  name,  description,  function,  algorithm, 
complexity,  domain,  technology,  collaborators,end2endDelay,  availability,  mobility.  The 
primary-key  in  this  table  is  the  id.  Example  of  a  record  of  this  table  is  as  follows: 
<'intrepid.cs.iupui.eduVAccountServerVProvides  An  Account  Management  SystemVActs 
As  An  Account  Server', 'Simple  Addition  And  Subtraction','0(l)','Financiar,'Java- 
RMr,'AccountClienf ,  1 0, 1 00,'No'> 

The  Function  table  serves  to  hold  a  list  of  all  functions  and  the  syntactic  contracts 
.  The  columns  in  this  table  are  id  which  references  id  of  the  Component  table, 
functionjiame  and  syntactic _contract.  The  combination  of  <id,  function jiame, 
syntactic _contract  >  serves  as  the  primary-key  for  this  table.  Example  of  a  record  of  this 
table  is  as  follows:  <'intrepid.cs.iupui.edu','javaDeposif,'void  javaDeposit(fioat  ip)'> 

5. 2. 4. 1.1. 4  Service  Components 

A  service  component  here  refers  to  a  software  unit  that  provides  a  service.  The 
service  provided  could  be  a  computational  effort  or  an  access  to  underlying  resources.  A 
service  component  consists  of  one  or  more  artifacts  (software,  hardware,  libraries)  that 
are  integrated  together  to  provide  the  service.  Service  Components  are  described  by  a 
remote  interface  and  an  implementation  for  this  interface.  Each  Service  Component  is  a 
stand-alone  functional  unit,  which  accepts  inputs  through  its  published  interfaces,  and 
returns  results.  Clients  or  other  components  can  remotely  access  a  service  component 
using  standard  communication  protocols.  Eor  a  component  to  be  remotely  accessible,  it 
should  be  deployed  in  a  runtime  environment  (e.g.  Application  Server)  with  ports  open  to 
receive  incoming  requests  and  return  results. 
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Figure  5.9  describes  an  example  of  a  stand-alone  remote  accessible  service 
component,  which  uses  the  HTTP  protocol  to  accept  and  return  results. 


Figure  5.9.  Example  of  a  Stand-Alone  Remote  Accessible  Service  Component. 

The  service  components  implemented  in  the  prototype  are  the  DSM,  QM,  HH, 
and  AR.  These  service  components  utilize  the  Entity  Objects  and  Helper  Objects  to 
achieve  their  functionalities  and  store  and  retrieve  information  from  their  respective 
repositories. 
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Figure  5.10.  Class  Diagrams  for  the  Service  Components 


Figure  5.10  illustrates  the  class  diagrams  of  the  Service  Components.  The  following  sub¬ 
sections  describe  these  service  components. 


5.2. 4.1. 1.4.1  Domain  Security  Manager  Service 

IDomainSecurityManager:  This  is  the  interface  for  the  DomainSecurityManager  service. 
This  interface  publishes  two  methods; 

•  getHHListForDomain:  This  method  is  invoked  by  the  QueryManager.  The 
purpose  of  this  method  is  to  return  a  list  of  registered  Headhunters  for  a  particular 
domain  to  the  QueryManager. 

•  authenticationService:  This  method  is  invoked  by  the  Headhunter  and 
ActiveRegistry  components  to  authenticate  themselves  with  the  DSM. 


DomainSecurityManager:  This  class  implements  IDomainSecurityManager  interface. 
The  implementation  is  based  on  the  algorithms  outlined  for  the  DSM  in  Chapter  4.  The 
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DSM  performs  the  functions  of  generating  secret-keys  for  the  domains  using  the 
CreateKey  helper  class.  It  authenticates  the  principals  against  the  DSM  Repository  with 
the  help  of  the  DSMRepositoryHelper  and  distributes  the  secret-keys  and  multicast 
addresses  to  Headhunters  and  Active  Registries.  The  communication  between  the  parties 
is  based  on  RMI-JRMP. 

5. 2.4. 1.1. 4.2  Query  Manager  Service 

IQueryManager:  This  is  the  interface  for  the  QueryManager  service.  This  interface 
publishes  the  following  method; 

•  getSearchResultTable:  This  method  is  invoked  by  the  RequestProcessor  to  obtain 
a  list  of  services  matching  the  search  criteria  specified  by  a  component  assembler. 

QueryManager:  This  class  implements  the  IQueryManager  interface.  The 
QueryManager  class  propagates  the  search  query  as  a  Query  Bean  object  to  the  list  of 
Headhunter  components  obtained  from  DomainSecurityManager  and  returns  search 
results  to  the  RequestProcessor.  The  interaction  between  these  components  is  based  on 
RMI-JRMP. 

5. 2. 4. 1.1. 4. 3  Headhunter  Service 

IHeadhunter:  This  is  the  interface  for  the  Headhunter  service.  This  interface  publishes 
the  following  methods: 

•  performSearch:  This  method  is  invoked  by  the  QueryManager  to  propagate  a 
search  query. 

•  receiveUnicastCommunication:  This  method  is  invoked  by  the  ActiveRegistry  to 
inform  the  Headhunter  of  its  location. 

Headhunter:  This  class  implements  the  IHeadhunter  interface.  The  implementation  is 
based  on  the  algorithms  outlined  in  the  previous  Chapter  for  the  Headhunter  functions. 
The  Headhunter  class  interacts  with  the  QueryManager  and  DomainSecurityManager 
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using  RMI-JRMP.  The  Headhunter  uses  the  MulticastSender  to  multieast  enerypted 
messages  to  ActiveRegistry  serviees.  The  Headhunter  also  eommunieates  with  the 
AetiveRegistry  services  through  unicast  RMI-JRMP  for  the  purpose  of  obtaining  the 
component  information  as  a  Hashtable  of  ComponentBean  objects.  The  HeadHunter 
saves  this  component  information  to  the  MetaRepository  and  uses  the 
MetaRepository Helper  for  the  purpose  of  performing  searches  against  the  repository.  The 
SQL  query  for  the  searches  is  obtained  from  the  QueryBean  which  is  propagated  to  the 
Headhunter  by  the  QueryManager. 

5. 2.4. 1.1. 4  Active  Registry  Service 

I  ActiveRegistry:  This  is  the  interface  for  the  ActiveRegistry  service.  This  interface 
publishes  the  following  method: 

•  getComponentData:  This  method  is  invoked  by  the  Headhunter  to  retrieve 
component  information  from  the  ActiveRegistry. 

ActiveRegistry:  This  class  implements  the  I  ActiveRegistry  interface.  The  implementation 
is  based  on  the  algorithms  outlined  in  the  previous  Chapter  for  the  ActiveRegistry 
functions.  The  ActiveRegistry  class  receives  multicast  messages  from  the  Headhunter  by 
using  the  MulticastReceiver  class.  Interaction  with  the  Headhunter  for  passing  its  contact 
information  and  component  information  are  done  through  RMI-JRMP.  It  also 
communicates  with  the  DomainSecurityManager  for  authentication  purposes  using  RMI- 
JRMP.  The  ActiveRegistry  uses  the  UniFramelntrospector  for  the  purpose  of  obtaining 
the  UniFrame  specifications  of  the  components  registered  with  it.  It  also  uses  the 
UniFrameSpecificationParser  for  parsing  the  specifications  and  building  instances  of 
ComponentBean  objects,  which  it  returns  to  the  Headhunter. 

5. 2.4. 1.2  The  View 


The  view  determines  the  presentation  of  the  user  interface  of  the  prototype.  The 
components  that  work  together  to  implement  the  view  are  the  JSP  pages  and  the 
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JavaBeans  components.  The  JSP  pages  are  used  for  dynamie  generation  of  HTML 
responses.  JavaBeans  components  represent  the  contraet  between  JSP  pages  and  the 
model.  JSP  pages  rely  on  these  beans  to  read  model  data  to  be  rendered  to  HTML.  The 
following  are  the  JSP  pages,  whieh  present  a  View  to  the  user;  UniFrameQuery.jsp  (see 
Figure  5.11  and  Figure  5.12),  ComponentList.jsp  (see  Figure  5.13),  ComponentDetailjsp 
(see  Figure  5.14).  The  controller  functionality  associated  with  these  views  is  explained  in 
Section  5.2. 4. 1.3. 


Figure  5.11  UniFrameQuery.jsp  View 


Figure  5.11  and  5.12  illustrate  the  UniFrameQuery.jsp  view  which  allows  the  component 
assembler  or  system  integrator  to  specify  various  search  criteria. 
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Figure  5.12  UniFrameQuery.jsp  View  Continued. 


Figure  5.13  ComponentList.jsp  View 
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Figure  5.13  above  illustrates  the  view  ComponentList.jsp.  In  this  view  the  list  of 
eomponents  matehing  the  seareh  eriteria  is  displayed  to  the  eomponent  assembler.  The 
user  ean  eliek  on  the  Component  Details  hyperlink  to  view  the  details  of  a  partieular 
eomponent  whieh  takes  them  to  the  next  view  ComponentDetails.jsp  illustrated  in  Figure 
5.14.  The  ComponentDetails.jsp  view  provides  all  the  information  specified  by  the 
component  developer  in  the  UniFrame  specification  of  the  component. 


Figure  5.14  ComponentDetail.jsp  View 


5. 2.4. 1.3  Controller 

The  prototype  must  reflect  the  state  of  a  user's  interaction  with  the  discovery 
service  and  the  current  values  of  persistent  data  in  the  user  interface.  Following  the  MVC 
architecture,  this  functionality  is  implemented  within  the  controller.  The  controller  is 
responsible  for  coordinating  the  model  and  view.  The  following  controller  components 
provide  this  functionality  in  the  prototype; 
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UniFrameQuery.jsp:  Receives  and  processes  HTTP  requests.  The  servlet  generated  from 
UniFrameQuery.jsp  receives  all  HTTP  requests. 

ProcessUniFrameQuery.jsp:  Processes  the  information  from  the  HTTPRequest  to  create 
an  instance  of  QueryBean  and  passes  it  to  the  RequestProcessor,  which  coordinates  all 
handling  of  the  request. 

RequestProcessor:  RequestProcessor  provides  the  glue  in  the  Web  tier  for  holding  the 
application  components  together.  It  contains  logic  that  needs  to  be  executed  for  each 
request.  RequestProcessor  collaborates  with  the  QueryManager  and  gets  a  Hashtable  of 
search  results  from  the  QueryManager,  which  it  forwards  to  the  View  ComponentListjsp. 

ComponentListjsp:  Provides  a  master  view  of  the  lists  of  components  matching  the 
search  criteria. 

ComponentDetailJsp:  Provides  a  detail  view  that  describes  the  details  of  a  particular 
component.  Users  click  on  an  item  in  the  master  view  to  zoom  in  on  details,  including  a 
description,  and  other  details  of  the  UniFrame  specifications. 

5. 2.4. 1.3.1  Managing  the  State  of  a  Session 

Every  client  session  needs  to  track  the  information  associated  with  the  client 
requests  (client  query)  and  the  associated  responses  (results  matching  the  search  criteria). 
In  the  JSPs  an  HTTP  session  object  maintains  the  JavaBeans  that  are  specific  to  a  client. 
The  following  state  information  is  maintained. 

Query  Information:  The  information  associated  with  the  client  query  is  captured  in  the 
QueryBean  and  passed  on  to  the  QueryManager  via  the  RequestProcessor . 


The  Query  Results:  The  RequestProcessor  class  maintains  a  list  of  results  matching  the 
search  criteria.  The  result  list  is  stored  as  a  Hashtable  of  ComponentBean  objects  within 
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the  RequestProcessor  class.  These  results  are  displayed  in  the  ComponentListjsp  view  to 
the  users. 


5.3  Experimental  Results 

Some  experimental  tests  were  conducted  to  validate  the  performance  of  the 
prototype.  The  Service  Components  in  the  experimental  setup  comprised  of  one  ICB 
(having  a  QueryManager  and  a  DomainSecurityManager),  one  Headhunter  and  one 
ActiveRegistry  (extended  RMl  registry).  A  single  client  (Application  Client  Component) 
was  used  in  the  experiment.  The  experimental  tests  were  conducted  with  queries  having 
different  types  of  search  constraints. 

The  measurements  presented  are  averaged  over  100  trials  and  were  conducted  on 
Sun  Solaris  machines  running  Sun  Solaris  Unix  v5.8.  Sun’s  JDK  1.4  was  used  to  run  the 
components  of  the  URDS  system. 

The  following  performance  metrics  were  gathered: 

Average  Authentication  Time  (Tauth)-  This  is  computed  as  the  time  taken  by  the 
DomainSecurityManager  to  authenticate  a  principal.  It  is  computed  from  the  time  a 
Headhunter/ActiveRegistry  sends  the  DSM  its  authentication  credentials  to  the  time  it 
receives  a  response  from  the  DSM. 

Average  Query  Service  Time  (Tquery):  This  is  the  average  time  taken  to  service  a  query.  It 
is  computed  from  the  time  a  query  is  presented  by  a  client  to  the  URDS  system  to  the 
time  a  response  is  received. 

Average  Registry  Discovery  Time (T discovery  )■  This  is  the  average  time  taken  by  a 
Headhunter  to  discover  an  ActiveRegistry.  It  is  computed  from  the  time  the  Headhunter 
multicasts  its  location  to  the  time  it  receives  a  response  from  the  Registry.  This  time 
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includes  the  time  taken  by  the  AetiveRegistry  to  deerypt  the  enerypted  multieast 
eommunieation  reeeived  from  the  Headhunter. 

Average  Component  Information  Retrieval  Time  (T info-retrivai  )■  This  is  the  average  time 
taken  by  the  Headhunter  to  retrieve  eomponent  information  from  an  AetiveRegistry.  It  is 
eomputed  from  the  time  the  Headhunter  requests  an  AetiveRegistry  for  eomponent 
information  to  the  time  it  reeeives  a  response  from  the  AetiveRegistry.  This  time  ineludes 
the  time  taken  by  an  AetiveRegistry  to  obtain  the  UniFrame  Speeifieation  URLs  from  the 
list  of  eomponents  registered  with  it  and  to  parse  the  XML  speeifieations  to  extraet  the 
eomponent  information. 

The  Average  Authentieation  Time  was  eomputed  to  be  =  690.5  millisees. 

The  Average  Query  Serviee  Time,  Average  Registry  Diseovery  Time,  and  Average 
Component  Information  Retrieval  Time  were  ealeulated  for  the  following  two  oases: 

Varying  the  Time  period  between  suooessive  multioast  oyoles  of  the  Headhunter  (Tmcast) 
keeping  the  Number  of  Components  (Ncomponents)  registered  with  the  Aotive  Registry 
oonstant. 

Varying  the  Number  of  Components  (Ncomponents)  registered  with  the  Aotive  Registry 
keeping  the  Time  period  between  suooessive  multioast  oyoles  of  the  Headhunter  (Tmcast) 
oonstant. 

Figure  5.15  shows  the  variation  of  Tq^^jy^  T^i^covery  ,  Tifijo-fetj-iyal  with  Ncomponent  when  Tmcast 
was  kept  oonstant  at  5000  ms.  It  oan  be  observed  from  the  graph  that  the  average  time 
taken  the  Headhunter  to  disoover  registries  and  the  average  time  taken  to  serviee  a  query 
inorease  marginally  with  an  inoreasing  number  of  registered  eomponents.  However,  the 
time  taken  by  the  Headhunter  to  retrieve  eomponent  information  from  the  registries 
inoreases  substantially  with  inoreasing  number  of  registered  eomponents. 
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Figure  5.16  shows  the  V^rmtlOIl  of  Tquery,  ^discovery  .  T i^fo-retrival  With  Tmeast  wheil 

Ncomponent  was  kept  constaiit  at  10.  It  can  be  observed  from  the  graph  that  the  average  time 
taken  the  Headhunter  to  discover  registries  remains  almost  constant  with  increase  in  time 
period  between  successive  multicasts.  The  average  time  taken  to  service  a  query  and  the 
time  taken  by  the  Headhunter  to  retrieve  component  information  from  the  registries  also 
do  not  show  much  variation  until  the  time  period  between  multicast  cycles  is  increased  to 
5000  ms,  when  they  show  an  increase  in  the  time  taken. 
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5.4  Implementation  Strategies  for  Enhancing  the  Prototype 

This  section  discusses  implementation  strategies,  to  enhance  the  prototype  at  an 
application  level  and  make  the  implementation  more  scalable,  fault  tolerant, 
maintainable,  interoperable  and  secure.  The  strategies  outline  alternative  deployment 
environments  or  communication  protocols  that  can  be  used  to  implement  the  service 
components.  The  following  are  the  performance  areas  in  the  implementation  where  these 
strategies  are  applicable; 


Improving  Scalability  and  Fault  Tolerance  of  the  Implementation 
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The  prototype  applieation  supports  various  serviees  like  DSM,  QM,  HH,  ete.,  It  is 
desirable  that  these  serviees  be  able  to  handle  a  large  number  of  requests  for  serviees 
without  their  effieieney  being  adversely  affeeted.  Serviees  that  are  sealable  and  easy  to 
maintain  usually  have  better  QoS  ratings.  It  would  also  be  desired  that  these  serviees  be 
“available”  for  serviee  most  of  the  time  and  are  not  “unavailable”  due  to  reasons  sueh  as 
hardware/software  failure  or  “downtime”  due  to  maintenanee  upgrades  of  the 
software/hardware  units  they  are  deployed  in. 

A  suggested  implementation  for  realizing  these  requirements  is  to  deploy  the 
Serviee  Components  in  a  runtime  environment  sueh  as  an  Applieation  Server,  whieh 
supports  the  eoneept  of  Workload  Management.  An  example  of  sueh  an  applieation 
server  that  implements  Workload  Management  eapabilities  is  IBM’s  WebSphere 
Applieation  Server  4.0  [1BM02]. 

Workload  Management  (WLM)  is  the  proeess  of  spreading  multiple  requests  for  a 
serviee  over  resourees  that  ean  aeeomplish  the  task.  WLM  balanees  request  proeessing  by 
allowing  ineoming  work  requests  to  be  distributed  aeross  applieation  servers,  eontaining 
identieal  versions  of  the  serviee  ealled  ‘Clones’,  aeeording  to  a  eonfigured  WLM 
seleetion  poliey.  The  software/hardware,  whieh  dispatehes  requests  to  the  different 
servers  in  the  pool,  is  ealled  an  “IPSprayer”.  Workload  management  is  most  effeetive 
when  used  in  systems  that  eontain  servers  on  multiple  maehines.  It  ean  also  be  used  in 
systems  that  eontain  multiple  servers  on  a  single,  high-eapaeity  maehine.  This  enables  the 
system  to  make  the  most  effeetive  use  of  the  available  eomputing  resourees. 

If  a  server  in  the  pool  is  down  due  to  reasons  sueh  as  hardware/software  failure  or 
maintenanee  upgrades  then  the  requests  for  the  serviees  ean  be  direeted  to  another  server 
in  the  pool  eontaining  the  serviee  elone.  WLM  improves  the  performanee,  sealability  and 
reliability  of  an  applieation  by  providing  for  load  balaneing  and  failover  eapabilities. 
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Figure  5.17.  Improving  Scalability  with  WLM 
Figure  5.17  illustrates  WLM  across  two  servers. 

Interoperability  and  Asynchronous  Communication 

In  the  prototype  implementation,  the  service  components  such  as  DSM,  QM,  LM, 
HH,  AR  are  implemented  as  Java-RMl  based  services  which  communicate  with  each 
other  via  JRMP.  Alternative  implementations  could  be  to  structure  these  services  as 
Enterprise  JavaBeans  deployed  in  the  EJB  container  communicating  with  each  other  via 
RMl-llOP  or  as  SOAP  based  services  communicating  with  each  other  via  SOAP.  These 
protocols  promote  greater  interoperability  than  JRMP.  Using  SOAP  for  inter-component 
communication  removes  the  tight  coupling  that  currently  exists  between  the  service 
components.  Additionally,  SOAP,  being  a  firewall-friendly  protocol,  will  remove  the 
restrictions  present  in  the  current  implementation  of  the  services  having  to  be  located 
within  the  same  subnet.  This  is  especially  a  necessity  in  the  case  of  the  LinkManager  as 
this  will  enable  federation  with  external  LinkManager  components  (LinkManagers  in 
other  ICBs)  located  in  different  networks. 
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All  inter-component  communication  in  the  implementation  is  synchronous.  The 
users  are  waiting  on  the  QM  to  return  results  and  the  QM  is  waiting  on  the  Headhunters 
to  return  results.  Making  these  communications  asynchronous  and  using  remote  event 
notification  will  allow  a  user  greater  fiexibility  wherein  the  user  need  not  wait  until  the 
operation  completes  and  results  are  returned.  The  use  of  asynchronous  messaging  allows 
the  development  of  loosely-connected  systems.  These  systems  are  typically  more  resilient 
in  the  event  of  failures,  and  more  easily  extensible  as  new  applications  are  developed. 
Additionally,  messaging  provides  an  effective  means  of  transmitting  events  between 
applications.  Asynchronous  messaging  can  be  incorporated  into  the  implementation  using 
Java  Message  Service  (JMS).  The  service  components  can  be  structured  as  EJB 
components,  which  integrate  with  JMS  thus  allowing  the  enterprise  beans  to  participate 
fully  in  loosely  connected  systems.  The  EJB  service  components  can  then 
asynchronously  notify  other  components  of  the  occurrence  of  events.  Remote  event 
notification  features  will  allow  the  Model  to  notify  the  Controller  of  changes  in  events  in 
the  model,  which  can  be  rendered  as  Views  in  the  system. 

Securing  the  Implementation 

In  the  current  prototype  implementation  users  of  the  URDS  discovery  services  are 
not  authenticated  and  there  is  no  gradation  on  the  levels  of  access  that  the  users  may 
possess.  However,  on  a  going  forward  basis,  this  would  be  a  desired  feature,  as  service 
providers  may  not  wish  to  advertise  their  services  to  unauthorized  users,  or  depending  on 
the  privileges  the  users  possess,  they  may  allow  access  to  only  a  certain  set  of 
functionality  as  opposed  to  others.  The  authentication  aspect  for  users  can  be  handled 
through  a  form  based  userid/password  scheme.  Eor  supporting  users  with  different 
profiles,  structuring  the  service  components  as  EJB  components  allows  the 
implementation  to  leverage  the  role  based  security  services  offered  by  the  EJB 
architecture. 
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This  chapter  presented  an  implementation  for  the  URDS  arehitecture  and  the 
experimental  results.  The  ehapter  also  discussed  enhaneements  that  eould  be  made  to  the 
prototype. 

The  next  ehapter  eoneludes  the  thesis  by  presenting  a  eomparison  between  the 
URDS  arehiteeture  and  other  resouree  diseovery  protoeols  discussed  in  Chapter  2.  The 
ehapter  also  diseusses  possible  future  extensions  to  this  work. 
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6.  CONCLUSION 

This  thesis  presented  the  arehiteeture  and  an  implementation  for  a  resouree 
diseovery  serviee,  the  “UniFrame  Resouree  Diseovery  Serviee”.  The  resouree  diseovery 
serviee  itself  forms  a  part  of  a  framework,  “UniFrame”,  whieh  aims  at  providing  a 
platform  for  building  DCS  by  integrating  existing  and  emerging  distributed  eomponent 
eomputing  models  under  a  eommon  meta-model  that  enables  diseovery,  interoperability, 
and  eollaboration  of  eomponents  via  generative  software  teehniques.  Seetion  6.1 
diseusses  the  features  of  URDS  and  eompares  it  to  other  resouree  diseovery  serviees. 
Seetion  6.2  diseusses  possible  future  enhaneements  to  the  URDS  arehiteeture. 


6.1  Features  of  URDS 


A  diseussion  of  the  features  of  URDS  and  how  these  eompare  with  other  resouree 
diseovery  protoeols  is  presented  here: 


6.1.1  Interoperability 

Various  resouree  diseovery  protoeols  available  today  adhere  to  different 
“standards”  and  there  is  little  interoperability  between  them.  These  protoeols  have  been 
designed  to  provide  serviees  for  very  speeifie  models.  For  example,  the  CORBA  Trader 
serviees  offer  direetory  serviees  only  for  CORBA  objeets,  or  the  JINI  diseovery  serviees 
spontaneously  diseover  only  other  JINI  enabled  deviees.  For  these  protoeols  to  be 
logieally  eompatible,  they  need  to  be  mapped  by  implementing  equivalent  protoeols  or 
bridges  and  proxies.  This  defies  the  underlying  goal  of  “diseovery”  being  universal.  It  is 


124 


this  interoperability  gap  that  URDS  is  trying  to  bridge  by  providing  diseovery  and 
directory  services  for  components  developed  using  diverse  distributed  computing  models. 

URDS  tackles  the  issue  of  non-uniformity  with  the  assistance  of  the  ICB  and 
Headhunter  components  (explained  in  Chapter  3  and  Chapter  4).  The  Headhunters 
discover  heterogeneous  components.  Since  the  components  discovered  by  the 
Headhunters  do  not  share  common  semantics  for  communication,  the  ICB  provides  the 
capability  to  generate  the  glue  and  wrappers  for  components  implemented  in  diverse 
models  to  collaborate  across  the  Internet.  The  ICB  will  eventually  use  standard 
component  mappings  and  component  model  adapters  to  bridge  the  conceptual  model 
disparity.  Thus,  URDS  addresses  the  issue  of  bootstrapping  between  components 
implemented  in  diverse  architectures,  which  is  not  found  in  other  resource  discovery 
protocols. 

The  Headhunter  and  ICB  components  together  are  responsible  for  allowing  a 
seamless  integration  of  different  component  models  and  sustaining  (managed) 
cooperation  among  heterogeneous  components. 


6.1.2  Discovery  Mechanism 

It  is  essential  that  Discovery  Services  effectively  manage  the  bandwidth  usage.  It 
is  easy  to  saturate  the  network  if  the  services  implement  protocols,  which  do  not  consider 
bandwidth  as  a  critical  issue  (e.g.,  “if  services  and  clients  discover  each  other  by 
multicast/broadcast  once  per  second”).  Protocols  that  are  based  on  a  purely  advertisement 
or  purely  request  strategy  may  use  a  great  deal  of  bandwidth  [GUT99].  If  all  services 
keep  advertising  their  availability  periodically  and  if  clients  keep  sending  service  requests 
to  all  possible  services,  the  network  will  saturate  with  advertisements  and  requests,  and 
may  also  overload  service  providers.  It  is,  therefore,  imperative  that  multicast  be  used 
carefully  and  the  number  of  messages  exchanged  be  limited. 
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The  fundamental  difference  between  other  Service  Discovery  Protocols  and 
URDS  is  that,  in  the  URDS  architecture,  the  Clients  and  Services  are  not  ‘active’  i.e., 
they  do  not  directly  participate  in  the  multicast  communications  of  the  discovery  process. 
It  is  the  native  registries  that  have  a  handle  to  the  services  that  participate  in  the  discovery 
process  and  not  the  services  themselves.  The  advantage  of  this  approach  is  two  fold; 

1.  network  usage  is  reduced  as  the  Services  and  Clients  are  not  participating  in 
active  discovery,  which  cuts  down  on  the  multicast  messages  periodically  being 
broadcast/multicast  by  Services,  Clients,  and  Lookup  Services  wanting  to  be 
discovered  by  each  other. 

2.  service  providers  do  not  need  to  add  additional  functionality  to  their  components 
to  make  them  ‘active’  i.e.,  communication-aware.  The  components  can  be 
constructed  in  any  desired  component  model  and  still  be  discovered  in  the  URDS 
environment. 

The  URDS  architecture  of  combining  a  Directory  Service  with  a  Discovery 
service,  presents  another  unique  advantage  in  reducing  communication  overhead.  The 
ICB  acts  as  the  directory  for  brokering  client  requests.  Clients  contact  the  ICB  with  their 
service  requests,  and  the  ICB  responds  with  a  list  of  services  matching  the  service 
requests.  This  avoids  the  situation  of  the  client  being  swamped  with  responses  from 
arbitrary  services.  URDS  also  supports  Federation  of  the  ICBs,  which  further  helps  to 
localize  traffic  and  reduce  the  number  of  parties  involved.  The  idea  of  Federation  or 
Hierarchical  organizations  is  common  in  Directory  Services,  and  this  can  prove  very 
efficient  when  combined  with  a  Discovery  service. 


6.1.3  Service  Description 


Every  resource  discovery  protocol  specifies  its  own  standards  for  describing 
services.  The  Object  Management  Group  (OMG)  specifies  the  standard  Interface 
Definition  Language  (IDE)  for  defining  service  contracts.  W3C  has  focused  on  standards 
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for  exchanging  information  using  the  Internet  infrastructure  (HTML,  XML,  HTTP,  XSL). 
URDS  aims  to  discover  and  achieve  interoperability  in  an  open,  dynamic  network 
environment  where  the  communicating  parties  (clients  and  services)  are  implemented  in 
diverse  architectures  each  conforming  to  their  own  standards  of  service  description.  It 
was  realized  that  it  would  not  be  possible  to  implement  a  meta-protocol  of  service  types. 
The  solution  adopted  in  URDS  is  to  allow  the  components  to  follow  their  own  standards 
for  service  description  but  also  provide  a  UniFrame  specification  in  XML  outlining  the 
computational,  functional,  co-operational,  auxiliary  attributes  and  QoS  metrics.  Since, 
XML  is  designed  to  support  an  automatic  translation  and  transformation  between  XML 
languages,  it  is  well  suited  for  providing  interoperability  between  diverse  services.  The 
UniFrame  Approach  also  provides  capabilities  for  auto-generating  the  XML  based 
UniFrame  specifications  from  the  natural  language  specification  of  the  component. 


6.1.4  Client  Query  and  Matchmaking 

In  URDS,  the  users  (clients)  present  a  query  to  the  system  in  natural  language-like 
style.  This  query  is  passed  through  a  natural  language  query  processor,  which  extracts  the 
key  words,  constraints,  and  preferences  (see  Chapter  4)  from  the  query  and  constructs  a 
structured  query  language  statement.  The  matchmaking  is  achieved  by  comparing  the 
structured  query  language  statement  against  the  repository  of  service  information.  This 
method  of  query  and  matchmaking  allows  a  user  a  large  degree  of  flexibility  in 
formatting  queries,  which  is  not  found  in  any  of  the  other  discovery  or  directory  services. 
The  JINI  searching  mechanism  uses  the  Java  serialized  object-matching  mechanism, 
which  is  based  on  exact  matching  of  serialized  objects,  making  it  prone  to  false  negatives 
due  to  class  versioning  problems  [CZE99].  The  SSDS  searching  mechanism  is  based  on 
XML  tag  matching  while  SLR  is  based  on  matching  of  service  types  all  of  which  require 
the  client’s  query  to  adhere  to  a  standard  format  in  order  to  obtain  a  match. 
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6.1.5  Domain  of  Discovery 

The  discovery  protoeol  of  the  URDS  arehitecture  is  “administratively  scoped”, 
i.e.,  it  locates  services  within  an  administratively  defined  logieal  domain.  Domain  in  the 
UniFrame  Approach  refers  to  industry  speeific  markets  sueh  as  Financial  Services, 
Health  Care  Serviees,  Manufaeturing  Serviees.  In  URDS,  the  Headhunters  and  Active- 
Registries  are  assoeiated  with  speeific  domains  and  they  register  and  deteet  serviees 
developed  for  the  speeific  industrial  sector  with  which  they  are  assoeiated.  This  kind  of 
logieal  partitioning  also  allows  for  a  contextualization  of  the  seareh  space.  Other 
diseovery  protoeols  too  have  the  notion  of  “administrative  scope”  but  the  difference  in 
their  ease  is  that  seope  is  assoeiated  with  the  topology  of  the  network  domain.  The 
resourees  detected  in  these  cases  are  those  that  are  logieally  located  ‘nearby’  within  the 
network  topology. 


6.1.6  Seeurity 

Most  Direetory  Serviees  do  not  have  a  built-in  security  framework.  Security  is  not 
as  essential  in  these  cases  because  of  the  centralized  management  sehemes.  Discovery 
protoeols  however  need  to  address  this  issue  because  of  their  deeentralized  nature. 
Diseovery  protoeols  are  faeed  with  the  ehallenge  of  providing  a  robust,  yet  lightweight, 
and  automatie  security  protocol  that  does  not  consume  network  resources. 

The  UniFrame  architeeture  addresses  a  majority  of  the  seeurity  threats  faeed  in 
the  scenario  of  a  discovery  process.  The  seeurity  model  provides  for  authentieation  of  the 
prineipals  involved  (Headhunters  and  native  registries)  through  a  userid-password  based 
authentieation  seheme.  URDS  uses  access  eontrol  lists  to  restrict  access  to  multicast 
address  resources.  URDS  also  ensures  the  security  of  the  multicast  data  transmitted 
through  the  use  of  a  seeret-key  based  data  eneryption  seheme.  The  model  does  not  at  this 
stage  provide  for  elaborate  protoeols  for  establishing  keys  and  passwords.  It  uses  a 
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centralized  controller  (the  Domain  Security  Manager),  whieh  is  responsible  for 
authentieating  the  principals  and  distributing  the  seeret-keys. 

The  Ninja:  SSDS,  outlined  in  Chapter  2,  is  a  good  example  as  it  uses  several 
different  security  protocols  and  services.  SSDS  uses  Certificates  and  a  Certifieate 
Authority  structure  to  authentieate  all  principals.  The  authenticity  of  the  discovery  service 
is  maintained  through  Public  Key  authenticated  SDS  server  announcements.  Privacy  and 
authenticity  of  service  descriptions  are  ensured  through  one-way  enerypted  serviee 
announcements  (eombined  publie  and  private  key  protoeol).  SSDS  uses  Secure  RMI  for  a 
two-way  authenticated  and  enerypted  remote  method  invocation. 

The  other  protoeols  like  JINI  and  SLP  have  support  for  authentieation,  but  no 
provisions  for  encryption. 


6.1.7  Quality  of  Service 

A  unique  feature  of  URDS  is  the  incorporation  of  the  notion  of  QoS  as  applied  to 
software  eomponents.  Although  QoS  parameters  and  assoeiated  metrics  have  been  widely 
used  in  networking,  there  is  no  standard  voeabulary  for  discussing  QoS  as  it  relates  to 
distributed  computing  and  component  based  solutions.  The  UniFrame  researeh  aims  at 
outlining  an  approaeh  to  a  QoS-based  framework  for  creating  distributed  heterogeneous 
software  components  [RAJOl].  This  work  leverages  work  by  Zinky,  Bakken  &  Sehantz 
[ZIN95]  with  the  goal  of  providing  a  eatalog  of  QoS  parameters,  indicating  how 
parameters  might  be  described,  and  providing  a  list  and  brief  description  of  the  QoS 
parameters  being  cataloged  along  with  a  detailed  sample  deseription.  The  discovery 
serviees  of  the  UniFrame  integrate  this  notion  of  QoS  into  the  speeification  of  serviees 
and  the  matchmaking  process.  The  UniFrame  specification  of  a  component  indicates  the 
various  QoS  metries  supported  by  a  eomponent  and  the  clients  issue  requests  for 
components  possessing  desired  levels  of  QoS.  The  matchmaking  process  then  uses  the 


129 


QoS  metrics  as  an  additional  level  of  filtration  to  return  the  appropriate  match  to  the 
client. 


6.2  Future  Work 


This  thesis  proposed  an  architecture  for  discovering  services  developed  in 
different  component  models.  The  proposed  architecture  was  validated  through  a 
prototype.  The  prototype  implements  the  following  features  of  the  URDS  architecture:  i) 
Dynamic  Discovery  of  components,  which  are  developed  using  the  Java-RMI,  distributed 
computing  model,  ii)  Servicing  Component  Assembler’s  requests  presented  in  natural 
language-like  style,  and  iii)  Security  features  outlined  in  the  URDS  architecture. 

Future  extensions  to  this  research  involve  more  comprehensive  and  complete 
implementation  and  a  more  rigorous  validation  of  the  features  proposed  in  the  URDS 
architecture,  which  are  not  currently  implemented  in  the  prototype.  This  is  outlined  in 
Section  6.2.1.  Section  6.2.2  outlines  research  possibilities  to  extend  the  URDS 
architecture. 


6.2.1  Extensions  to  the  Prototype  Implementation 

Many  extensions  are  possible  of  the  current  prototype.  A  few  of  these  are: 

•  Discovery  of  components  developed  using  other  distributed  computing  models 
such  as  CORBA,  Voyager,  etc.,  by  extending  the  native  registries  of  the 
respective  models  in  accordance  with  algorithms  outlined  in  Section  4.8.1  of 
Chapter  4. 
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•  A  support  for  Federation  of  ICBs  by  providing  for  an  implementation  of  the  Link 
Manager  Serviee  in  aeeordanee  with  the  algorithms  outlined  in  Seetion  4.4.1  of 
Chapter  4. 

•  A  support  for  Adapter  Component  Services.  This  will  require  further  research  in 
the  area  of  developing  adapter  components  by  using  glue  and  wrapper  technology. 
The  URDS  architecture  provides  the  Adapter  Manager  Service  (refer  Algorithms 
outlined  in  Section  4.5.1)  for  the  discovery  of  these  adapter  components. 

•  A  support  for  the  failure  detection  capabilities  in  the  Headhunter  outlined  in 
algorithm  4. 6. 1.6  of  Chapter  4. 

•  The  performance  of  the  prototype  can  be  optimized  by  fine  tuning  various 
parameters  such  as  the  time  between  periodic  multicast  announcements  by  the 
Headhunter,  the  time  period  between  successive  purge  cycles  to  maintain  the 
‘freshness’  of  the  information  returned  as  a  result  of  a  search,  and  the  number  of 
Headhunters  present  in  the  system  per  domain,  etc. 

•  The  performance  of  the  prototype  from  an  implementation  perspective  can  be 
enhanced  using  alternative  technologies  for  implementation.  Section  5.5  in 
Chapter  5  outlines  implementation  strategies  for  enhancing  the  prototype. 

•  Testing  the  scalability  and  incorporating  the  feedback. 


6.2.2.  Enhancements  of  the  URDS  Architecture 


Possible  areas  for  enhancement  of  the  current  architecture  are: 
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•  ‘Intelligent’  Search  Process:  The  search  propagation  process  in  URDS  can  be 
made  ‘intelligent’  i.e.,  the  search  process  can  use  decision  making  capabilities  to 
restrict  the  search  space  and  perform  more  ‘selective’  searches.  The  URDS 
architecture  proposed  the  use  of  query  propagation  policies,  search  scoping 
policies  and  function  scoping  policies  to  restrict  the  search  space  (See  Section  4.3 
of  Chapter  4).  The  process  can  be  further  improved  if  the  search  process  utilizes 
heuristics  such  as:  a)  past  history  and  statistical  results,  and  b)  notion  of 
acquaintances  to  narrow  the  search  space.  The  QM  can  use  heuristics  to  propagate 
a  search  to  Headhunters  and  Link  Managers.  The  QM  can  base  the  decision  to 
propagate  a  query  on  parameters  such  as  past  history  of  availability,  response 
time,  number  and  quality  of  search  results  obtained  from  a  Headhunter/Link 
Manager. 

•  Mobile  Headhunters:  The  Headhunters  in  the  current  implementation  use  the 
network  communication  to  gather  information  from  the  Active  Registries.  A 
possible  enhancement  could  be  to  make  the  Headhunters  ‘mobile’  i.e.,  the 
Headhunters  move  to  the  machines  hosting  the  registries  to  gather  information 
from  the  registries.  The  performance  advantage  of  such  an  approach  over  the 
current  approach  needs  to  be  carefully  weighed  out  as  it  raises  several  security 
concerns. 

•  Usages  of  alternative  schemes  for  techniques  such  as  Security  to  create  domain- 
specific  (and  restricted)  versions  of  URDS  are  other  directions  of  enhancement. 


6.3  Summation 


The  thesis  has  presented  an  architecture  and  an  implementation  for  the  part  of  an 
infrastructure  facilitating  a  semi-automatic  construction  of  a  distributed  system  that 
provides  for  the  dynamic  discovery  of  heterogeneous  components  and  selection  of 
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components  meeting  the  neeessary  requirements,  ineluding  desired  levels  of  QoS.  The 
URDS  arehiteeture  addresses  essential  design  issues  sueh  as  interoperability,  QoS  of 
software  eomponents,  scalability,  fault  tolerance,  security  and  network  usage.  These 
issues,  eonsidered  in  the  design  of  URDS,  make  it  unique  as  eompared  to  other  existing 
approaehes.  Interoperability  is  aehieved  by  diseovering  eomponents  developed  in  several 
different  eomponent  models.  The  diseovery  meehanism  uses  multieasting  to  deteet  native 
registries/lookup  serviees  of  various  eomponent  models  that  are  extended  to  possess 
‘aetive’  and  ‘introspeetive’  eapabilities.  The  speeifieations  eapture  the  eomputational, 
funetional,  co-operational,  auxiliary  attributes  and  QoS  metrics  of  their  registered 
eomponents.  Flexibility  in  query  formatting  is  achieved  by  providing  support  for  natural 
language-like  elient  requests.  URDS  is  organized  in  a  federated  hierarehical  structure  as  a 
sealability  meehanism.  Failure  toleranee  is  handled  through  periodie  announeements  by 
failure  prone  entities  and  through  information  eaehing.  Seeurity  is  provided  through 
authentieation  of  the  prineipals  involved,  aeeess  eontrol  to  multicast  address  resourees, 
and  eneryption  of  data  transmitted.  The  URDS  arehiteeture  eoupled  with  the  UA  presents 
a  promising  solution  for  ereating  DCS  by  integrating  geographieally  seattered, 
heterogeneous  software  eomponents. 


APPENDIX 


Source  Code 


umm . entity . beans . AuthenticatedPacket 

package  umm. entity. beans; 

import  java.io.*; 
import  j  avax . crypto . * ; 
import  java . security. * ; 

/  *  * 

*  The  AuthenticatedPacket  encapsulates  the  multicast  address  and 

*  secret-key  returned  to  the  principals  (Headhunters/ActiveRegistries)  by  the  Domain 

*  Security  Manager. 

*  Creation  date;  (03/01/2002  6:19:08  PM) 

*  @author;  Nanditha  Nayani  Siram 
*/ 

public  class  AuthenticatedPacket  implements  Serializable  { 
private  SecretKey  secretkey  =  null; 
private  String  mcastaddress  =  null; 

/  *  * 

*  The  AuthenticatedPacket  Constructor 
*/ 

public  AuthenticatedPacket (SecretKey  key.  String  address)  { 
secretkey  =  key; 
mcastaddress  =  address; 

} 

/  *  * 

*  Returns  Secret-Key 
*/ 

public  SecretKey  getKeyO  { 
return  secretkey; 

} 

/  *  * 

*  Returns  Multicast  Address 
*/ 

public  String  getMCAddress ( )  { 

return  mcastaddress; 

} 

/  *  * 

*  Set  Multicast  Address 
*/ 

public  void  setMCAddress ( String  address)  { 
mcastaddress  =  address; 
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*  set  Secret-Key 
*/ 

public  void  setKey ( SecretKey  key) 
secretkey  =  key; 


uinm .  entity .  beans  .  ComponentBean 

package  umm. entity. beans; 
import  umm. helper . dataaccess .* ; 

import  java.util.*; 
import  java.sql.*; 
import  java.io.*; 


y  *  * 


*  The  attributes  of  the  ComponentBean  class  mirror  the 

*  fields  of  the  table  Component.  The  ComponentBean 

*  internally  holds  a  list  of  FunctionBean  objects. 

*  The  ComponentBean  has  functionality  built  in  to 

*  persist  it  to  a  database. 

*  Creation  date;  (11/14/2001  5:09:08  PM) 

*  @author;  Nanditha  Nayani  Siram 
*/ 


public 

{ 


class  ComponentBean  implements  Serializable 


private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 


j ava . lang . String  id  = 

j ava . lang . String  name  = 

j ava . lang . String  description  = 

j ava . lang . String  function  = 

j ava . lang . String  algorithm  = 

j ava . lang . String  complexity  = 

j ava . lang . String  technology  = 

java . lang. String  preprocessingCollaborators  = 

double  endSendDelay  =  0; 

double  availability  =  0; 

j ava . lang . String  mobility  =  "No"; 

j ava . util .Vector  functionBeanList  =  new  VectorO; 
java . lang. String  status  =  "Active"; 
j ava . lang . String  domain  = 


/  *  * 

*  ComponentBean  constructor  comment. 
*/ 

public  ComponentBean ( )  { 

super ( ) ; 

} 


/  *  * 

*  Add  the  function  beans  to  list. 

*/ 

public  void  addFunctionBeans (FunctionBean  functionBean)  { 
functionBeanList . addElement (functionBean) ; 

} 


/  *  * 

*  Populate  attributes  of  bean  from  ResultSet. 

*/ 

public  void  buildBean (ResultSet  resultSet)  throws  java . lang. Exception  { 

id  =  resultSet . getString ( "id" ) ; 
name  =  resultSet . getString ( "name" ) ; 
description  =  resultSet . getString  ( "description" ) ; 
domain  =  resultSet . getString ( "domain" ) ; 
function  =  resultSet . getString ( "function" ) ; 
algorithm  =  resultSet . getString ( "algorithm" ) ; 
complexity  =  resultSet . getString ( "complexity" ) ; 
technology  =  resultSet . getString ( "technology" ) ; 


preprocessingCol labor ators  =  resultSet.getString; "collaborators 
end2endDelay  =  resultSet . getDouble ( "end2endDelay" ) ; 
availability  =  resultSet . getDouble ( "availability" ) ; 
mobility  =  resultSet . getString ( "mobility" ) ; 


^  * 

*  Return  Algorithm 
*/ 

public  j ava . lang . String  getAlgorithm ( )  { 

return  algorithm; 

} 

^  * 

*  Return  availability 
*/ 

public  double  getAvailability ( )  { 

return  availability; 

} 

/  *  * 

*  Return  complexity 
*/ 

public  java . lang. String  getComplexity ( )  { 

return  complexity; 

} 

/  *  * 

*  Return  description 
*/ 

public  java . lang. String  getDescription ( )  { 

return  description; 

} 

/  *  * 

*  Return  domain 
*/ 

public  j ava . lang . String  getDomainO  { 
return  domain; 

} 

/  *  * 

*  Return  end2endDelay 
*/ 

public  double  getEnd2endDelay ( )  { 

return  end2endDelay ; 

} 

/  *  * 

*  Return  function 
*/ 

public  java . lang. String  getFunction ( )  { 

return  function; 


*  Return  functionBeanList 
*/ 

public  java .util .Vector  getFunctionBeanList ( ) 
return  functionBeanList; 

} 

/  *  * 

*  Return  id 
*/ 

public  java . lang. String  getIdO  { 
return  id; 

} 

/  *  * 

*  Return  mobility 
*/ 

public  java . lang. String  getMobility ( )  { 

return  mobility; 


/  *  * 

*  Return  name 


public  :iava .  lang.  String  getNameO  { 
return  name; 


*  Return  preprocessingCollaborators 
*/ 

public  java . lang. String  getPreprocessingCollaborators ( )  { 

return  preprocessingCollaborators; 

} 

/  *  * 

*  Return  status 
*/ 

public  java . lang. String  getStatusO  { 
return  status; 


*  Return  technology 
*/ 

public  java . lang. String  getTechnology ( )  { 

return  technology; 


*  Set  algorithm 
*/ 

public  void  setAlgorithm ( j ava . lang . String  newAlgorithm)  { 
algorithm  =  newAlgorithm; 


*  Set  availability 
*/ 

public  void  setAvailability (double  newAvailability) 
availability  =  newAvailability; 


*  Set  complexity 
*/ 

public  void  setComplexity ( j ava . lang . String  newComplexity ) 
complexity  =  newComplexity; 


*  Set  description 
*/ 

public  void  setDescription ( j ava . lang . String  newDescription)  { 
description  =  newDescription; 

} 

/  *  * 

*  Set  domain 
*/ 

public  void  setDomain ( j ava . lang . String  newDomain)  { 
domain  =  newDomain; 


*  Set  end2endDelay 
*/ 

public  void  setEnd2endDelay (double  newEnd2endDelay)  { 
end2endDelay  =  newEnd2endDelay; 

} 

/  *  * 

*  Set  function 
*/ 

public  void  setFunction ( j ava . lang . String  newFunction)  { 
function  =  newFunction; 

} 

/  *  * 

*  Return  functionBeanList 


public  void  setFunctionBeanList (java .util .Vector  newFunctionBeanList)  { 
functionBeanList  =  newFunctionBeanList; 


public 


void  setid ( j ava . lang . String  newld) 
id  =  newld; 


mobility 


public 


void  setMobility ( j ava . lang . String  newMobility)  { 
mobility  =  newMobility; 


public 


void  setName ( j ava . lang . String  newName) 
name  =  newName; 


*  Set  preprocessingCollaborators 
*/ 

public  void  setPreprocessingCollaborators (java . lang. String  newPreprocessingCollaborators) 

{ 

preprocessingCollaborators  =  newPreprocessingCollaborators; 


public 


void  setStatus (java . lang. String  newStatus) 
status  =  newStatus; 


technology 


public 


void  setTechnology ( j ava . lang . String  newTechnology)  { 
technology  =  newTechnology; 


/  *  * 

*  Persist  Bean  values  to  database. 

*/ 

public  void  persistBean  (SQLHelper  sqlHelper)  throws  java . lang. Exception  { 


String  componentUpdateString  = 
"INSERT  INTO  COMPONENT  VALUES ("  + 

"  '  "  +  id  +  " '  ,  "  + 

" ' "  +  name  +  " ' , "  + 

" ' "  +  description  +  " '  ,  "  + 

"  '  "  +  function  +  " '  ,  "  + 

"  '  "  +  algorithm  +  " '  ,  "  + 

" ' "  +  complexity  +  " '  ,  "  + 

" ' "  +  domain  +  " ' , "  + 

" ' "  +  technology  +  " '  ,  "  + 

II  f  II  _|_  preprocessingCollaborators  + 
end2endDelay  +  + 

availability  +  + 

" ' "  +  mobility  +  "  '  "  + 


sqlHelper .updateTable (componentUpdateString) ; 

for(int  i=0; i<functionBeanList .size ( ) ; i++) 

{ 

FunctionBean  functionBean  =  (FunctionBean)  functionBeanList.get (i) 
functionBean . persistBean (sqlHelper) ; 


}//End  of  ComponentBean 


uinin .  entity .  beans  .  FunctionBean 

package  umm. entity. beans; 
import  umm. helper . dataaccess ; 


I 


import  java .util . * ; 
import  java.io.*; 

/  *  * 

*  The  attributes  of  the  FunctionBean  mirror  the  fields 

*  of  the  table  Function.  The  FunctionBean  has 

*  functionality  built  in  to  persist  it  to  a  database. 

*  Creation  date:  (11/15/2001  11:50:10  AM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  FunctionBean  implements  Serializable! 

private  java . lang. String  functionName  = 
private  java . lang. String  syntacticContract  = 
private  java . lang. String  id  = 

/  *  * 

*  FunctionBean  constructor  comment. 

*/ 

public  FunctionBean ( )  { 

super ( ) ; 

} 

/  *  * 

*  Construct  Bean  from  ResultSet. 

*/ 

public  void  buildBean ( j ava . sql . ResultSet  resultSet)  throws  j ava . lang . Exception  { 

id  =  resultSet . getString ( "id" ) ; 

functionName  =  resultSet . getString ( "function_name" ) ; 
syntacticContract  =  resultSet . getString ( "syntactic_contract" ) ; 

} 

/  *  * 

*  Return  Function  Name 
*/ 

public  j ava . lang . String  getFunctionName ( )  { 

return  functionName; 

} 

/  *  * 

*  Return  Sytactic  Contract 
*/ 

public  java . lang. String  getSyntacticContract ( )  { 

return  syntacticContract; 

} 

/  *  * 

*  Set  Function  Name 
*/ 

public  void  setFunctionName (java . lang. String  newFunctionName)  { 
functionName  =  newFunctionName; 

} 

!  -k  -k 

*  Set  Syntactic  Contract 
*/ 

public  void  setSyntacticContract ( j ava . lang . String  newSyntacticContract)  { 
syntacticContract  =  newSyntacticContract; 

} 

!  k  k 

*  Return  ID 
*/ 

public  java . lang. String  getIdO  { 
return  id; 


*  Set  ID 
*/ 

public  void  setid ( j ava . lang . String  newld)  { 
id  =  newld; 

} 

/  *  * 

*  Persist  Bean  onto  DB. 

*/ 

public  void  persistBean (SQLHelper  sqlHelper)  throws  Exception  { 

String  functionUpdateString  = 

"INSERT  INTO  FUNCTION  VALUES ("  + 

"  '  "  +  id  +  " ' , "  + 

II .  II  _|_  functionName  +  "  '  ,  "  + 

+  syntacticContract  + 

sqlHelper .updateTable (functionUpdateString) ; 

} 

}//end  of  FunctionBean 


uinin .  entity .  beans  .  QueryBean 

package  umm. entity. beans; 


import  java .util . * ; 
import  java.io.*; 


/  *  * 

*  The  QueryBean  encapsulates  the  attributes  of  a  Query 

*  received  from  the  client.  The  bean  also  has  the  logic 

*  associated  with  generating  a  SQL  query  based  on  the 

*  attributes  it  holds. 

*  Creation  date:  (11/15/2001  1:15:26  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 


public  class  QueryBean  implements  Serializable! 
private  java . lang. String  domain  = 
private  java . lang. String  componentName  = 
private  java . lang. String  componentDescription  = 
private  java . lang. String  functionNames  = 
private  java . lang. String  algorithms  = 
private  java . lang. String  complexity  = 
private  java . lang. String  technology  = 

private  java . lang. String  availabilityConstraint 
private  boolean  availabilityFlag  =  false; 
private  double  availabilityValue  =  0; 


private 

private 

private 

private 

private 

private 

private 

private 


boolean  end2endDelayFlag  =  false; 

j ava . lang . String  end2endDelayConstraint  = 

double  end2endDelayValue  =  0; 

j ava . lang . String  mobility  =  "No"; 

int  numOffers  =  0; 

int  numMetrics  =  0; 

int  hopcount; 

j ava . lang . String  requestID; 


/  *  * 

*  QueryBean  constructor  comment. 
*/ 

public  QueryBean 0  { 

super ( ) ; 


!  -k  -k 


Returns  algorithms  Query 


public  String  getAlgorithmQuery ( )  { 

String[]  stringTokens  =  tokeniseString (algorithms) ; 
StringBuffer  queryBuilder  =  new  StringBufferO; 
queryBuilder . append ( "  (  "); 

for(int  1  =0 ; ItstringTokens . length; ill) 


+  "%'  "  + 


String  searchQuery  = 

"  ( "  + 

"  UPPER (ALGORITHM)  LIKE  '%"  +  StringTokens [ 1 ]. toUpperCase ( ) 


queryBuilder . append (searchQuery) ; 


if ( ( i+1 ) <stringTokens . length) 
queryBuilder . append ( "  OR  "); 


queryBuilder . append ( "  )  "); 
return  queryBuilder  .toStringO; 


*  Return  availability  query. 

*/ 

public  String  getAvailabilityQuery ( )  { 

String  availabilityQuery  =  null; 

if ( (availabilityConstraint  !=  null)  && 
!  (availabilityConstraint . equalsIgnoreCase ("None") ) ) 


availabilityQuery  = 

"  ( "  + 


"  AVAILABILITY  "  +  availabilityConstraint  + 


availabilityValue  + 


availabilityQuery  = 

"  ( "  + 

"  AVAILABILITY  >  0"  + 


return  availabilityQuery; 


*  Return  complexity  query. 


public  String  getComplexityQuery ( ) 


String)]  stringTokens  =  tokeniseString ( complexity ) , 
StringBuffer  queryBuilder  =  new  StringBufferO; 
queryBuilder . append ( "  (  "); 

for(int  i  =0 ; itstringTokens . length; i++) 


String  searchQuery  = 

"  ( "  + 

"  UPPER (COMPLEXITY)  LIKE  '%"  + 
StringTokens [i] . toUpperCase ( )  +"%'  "  + 


queryBuilder . append (searchQuery) ; 


} 


if ( ( i+1 ) <stringTokens . length) 
queryBuilder . append ( "  OR  "); 


queryBuilder . append ( "  )  "); 
return  queryBuilder . toString ()  ; 


/  *  * 

*  Return  component  description  query. 

*/ 

public  String  getComponentDescriptionQuery ( )  { 

String)]  stringTokens  =  tokeniseString (componentDescription) ; 
StringBuffer  queryBuilder  =  new  StringBufferO; 
queryBuilder . append ( "  (  "); 

for(int  i  =0 ; i<stringTokens . length; i++) 

{ 


String 


stringTokens [i] . toUpperCase ( ) 


searchQuery  = 

"  ( "  + 

"  UPPER (DESCRIPTION) 

+"%'  "  + 


LIKE  ' 


+ 


} 


queryBuilder . append (searchQuery) ; 

if ( ( i+1 ) <stringTokens . length) 
queryBuilder . append ( "  OR  "); 


queryBuilder . append ( "  )  "); 
return  queryBuilder . toString ()  ; 

} 

/  *  * 

*  Return  component  name  query. 

*/ 


public  String  getComponentNameQuery ( )  { 


String)]  stringTokens  =  tokeniseString ( componentName ) ; 
StringBuffer  queryBuilder  =  new  StringBufferO; 
queryBuilder . append ( "  (  "); 


for(int  i  =0 ; i<stringTokens . length; i++) 

{ 


String  searchQuery  = 

"  ( "  + 

"  UPPER(NAME)  LIKE  '%"  +  StringTokens  ) i ]. toUpperCase ( )  +’ 


queryBuilder . append (searchQuery) ; 


if ( ( i+1 ) <stringTokens . length) 
queryBuilder . append ( "  OR  ") 


queryBuilder . append ( "  )  "); 
return  queryBuilder . toString () ; 


/  *  * 

*  Return  Domain  Query. 

*/ 

public  String  getDomainO  ) 
return  domain; 


*  Return  End2EndDelay  Query. 


V 


public  String  getEnd2EndDelayQuery ( )  { 

String  end2endDelayQuery  =  null; 


if ( (end2endDelayConstraint  !=  null)  && 

! (end2endDelayConstraint . equalsIgnoreCase ("None") ) ) 

{ 

end2endDelayQuery  = 

"  ( "  + 

"  END2ENDDELAY  "  +  end2endDelayConstraint  +  "  "  +  end2endDelayValue  + 


} 

else 


end2endDelayQuery  = 
'  ("  + 

'  END2ENDDELAY  >  0"  + 


return  end2endDelayQuery ; 


/* 


*  Return  Function  names  Query. 


V 


public  String  getFunctionNamesQuery ( ) 


String)]  stringTokens  =  tokeniseString ( functionNames ) ; 
StringBuffer  queryBuilder  =  new  StringBuf f er ( ) ; 


queryBuilder . append ( "  (  "); 

for(int  i  =0 ; itstringTokens . length; i++) 


String  searchQuery  = 

"  ( "  + 

"  UPPER ( function_name )  LIKE  '%"  + 
stringTokens [i] . toUpperCase ( )  +"%'  "  + 

"  OR  "  + 

"  UPPER (syntactic_contract)  LIKE  '%"  + 
stringTokens [i] . toUpperCase ( )  +  "%'  "  + 


queryBuilder . append (searchQuery) ; 


if ( ( i+1 ) <stringTokens . length) 
queryBuilder . append ( "  OR  "); 


queryBuilder . append ( "  )  "); 
return  queryBuilder . toString () ; 

} 

/  *  * 

*  Return  Mobility  Query. 

*/ 

public  String  getMobilityQuery ( )  { 

String  mobilityQuery  = 

11(11  _|_ 

"  UPPER (MOBILITY)  LIKE  '%"  +  mobility , toUpperCase ()  +  "%'  "+ 


return  mobilityQuery; 


Return  Technology  Query. 


*/ 

public  String  getTechnologyQuery ( )  { 

String  technologyQuery  = 

11(11  _|_ 

"  UPPER (technology)  LIKE  '%"  +  technology . toUpperCase ( )  +  "%'  "+ 


return 


technologyQuery; 


/  *  * 

*  Return  Hop  Count. 

*/ 

public  int  getHopcount ( )  { 

return  hopcount; 

} 


/  *  * 

*  Return  requestID 
*/ 

public  java . lang. String  getRequestID ( )  { 

return  requestID; 

} 

/  *  * 

*  Set  Algorithms. 

*/ 

public  void  setAlgorithms (java . lang. String  newAlgorithms )  { 

algorithms  =  newAlgorithms; 

} 

/  *  * 

*  Set  availability  Constraint. 

*/ 

public  void  setAvailabilityConstraint ( j ava . lang . String  newAvailabilityConstraint)  { 
availabilityConstraint  =  newAvailabilityConstraint; 

} 

/  *  * 

*  Set  Availability  Flag. 

*/ 

public  void  setAvailabilityFlag (boolean  newAvailabilityFlag)  { 
availabilityFlag  =  newAvailabilityFlag; 

} 

/  *  * 

*  Set  Availability  Value. 

*/ 

public  void  setAvailabilityValue (double  newAvailabilityValue)  { 
availabilityValue  =  newAvailabilityValue; 

} 

/  *  * 

*  Set  Complexity. 

*/ 

public  void  setComplexity ( j ava . lang . String  newComplexity )  { 

complexity  =  newComplexity; 

} 

!  -k  -k 

*  Set  Component  Description. 

k  / 

public  void  setComponentDescription (java . lang. String  newComponentDescription)  { 
componentDescription  =  newComponentDescription; 

} 

!  k  k 

*  Set  Component  Name. 

k  / 

public  void  setComponentName (java . lang. String  newComponentName)  { 
componentName  =  newComponentName; 

} 

j  k  k 


public 


void  setDomain ( j ava . lang . String  newDomain) 
domain  =  newDomain; 


end2endDelayConstraint . 


public 


void  setEnd2endDelayConstraint ( j  ava . lang .String  newEnd2endDelayConstraint ) 
end2endDelayConstraint  =  newEnd2endDelayConstraint; 


*  Set  end2EndDelayFlag . 

*/ 

public  void  setEnd2endDelayFlag (boolean  newEnd2endDelayFlag) 
end2endDelayFlag  =  newEnd2endDelayFlag; 


*  Set  end2endDelayValue . 

*/ 

public  void  setEnd2endDelayValue (double  newEnd2endDelayValue) 
end2endDelayValue  =  newEnd2endDelayValue; 


function  names. 


public 


void  setFunctionNames ( j ava . lang . String  newFunctionNames) 
functionNames  =  newFunctionNames; 


mobility . 


public 


void  setMobility ( j ava . lang . String  newMobility) 
mobility  =  newMobility; 


numMetrics . 


public 


void  setNumMetrics ( int  newNumMetrics ) 
numMetrics  =  newNumMetrics; 


numOf f ers . 


public 


void  setNumOf f ers ( int  newNumOf f ers )  { 

numOffers  =  newNumOf f ers ; 


Technology 


public 


void  setTechnology ( j ava . lang . String  newTechnology) 
technology  =  newTechnology; 


hopCount 


public 


void  setHopcount (int  newHopcount)  { 
hopcount  =  newHopcount; 


*  Set  requestID 
*/ 

public  void  setRequestID (java . lang. String  newRequestID) 
requestID  =  newRequestID; 


*  Tokenize  keywords. 
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*/ 

public  String []  tokeniseString ( String  keywords)  { 

String []  stringTokens  =  null; 
if  (keywords  !=  null)  { 

StringTokenizer  strTok  =  new  StringTokenizer (keywords) ; 
int  numTokens  =  strTok . countTokens () ; 
stringTokens  =  new  String [numTokens] ; 
int  i  =  0; 

while  ( StrTok . hasMoreTokens 0 )  { 

stringTokens [ i ]  =  strTok .nextToken(); 
i++; 


} 


return  stringTokens; 


} 

/  *  * 

*  Return  resultant  composed  query. 

*/ 

public  String  getQueryO  { 

String  componentTable  =  "COMPONENT  A"; 

String  functionTable  =  "FUNCTION  B"; 

String  baseQuery  =  "SELECT  *  FROM  "  +  componentTable  +  ",  "  + 

functionTable  +"  WHERE  (A. ID  =  B.ID)"; 


String  bodyQuery  = 

if  ( (componentName  !=null)  &&  (! componentName . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getComponentNameQuery ( ) ; 

} 

if  ( (componentDescription  !=null)  &&  (! componentDescription . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getComponentDescriptionQuery ( ) ; 

} 

if  ( (functionNames  !=null)  &&  (! functionNames . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getFunctionNamesQuery ( ) ; 

} 

if  ((algorithms  !=null)  &&  (! algorithms . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getAlgorithmQuery ( ) ; 

} 

if  ((complexity  !=null)  &&  (! complexity . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getComplexityQuery ( ) ; 

} 


if  ((technology  !=null)  &&  (! technology . equals ("")) )  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getTechnologyQuery ( )  ; 

} 

if  (availabilityFlag)  { 

bodyQuery  =  bodyQuery  +  "  AND  "  +  getAvailabilityQuery ( )  ; 

} 


if 


(end2endDe lay Flag) 
bodyQuery 

} 


bodyQuery  +  "  AND  "  +  getEnd2EndDelayQuery ( ) ; 


if 


((mobility  !=null) 
bodyQuery 


&&  ( (mobility. equalsIgnoreCase ("No")  )  )  { 

=  bodyQuery  +  "  AND  "  +  getMobilityQuery ( ) ; 


String  query  =  baseQuery  +  bodyQuery; 
return  query; 


}//end  QueryBean 


uirnn . helper . dataaccess . DSMRepositoryHelper 

package  umm. helper .dataaccess; 

import  java.sql.*; 
import  java.util.*; 


*  This  class  performs  functions  associated  with 

*  accessing  the  DSM_Repository  to  retrieve 

*  user-domain  mappings  and  for  user  authentication. 

*  Creation  date;  (11/15/2001  1:15:26  PM) 

*  @author;  Nanditha  Nayani  Siram 


public  class  DSMRepositoryHelper  { 


private  static  SQLHelper  sqlHelper  =  null; 


*  Initialize  SQLHelper 
*/ 

public  static  void  initialize ()  { 

try  { 

sqlHelper  =  new  SQLHelperO; 

}  catch  (Exception  e)  { 

System. out. println (e) ; 


*  authenticate  principal  against  DB. 

*/ 

public  static  boolean  authenticateUser ( 
String  sUserType, 

String  sUserName, 

String  sPassword)  { 

boolean  isAuthenticated  =  false; 


String  sUserQuery  = 

"SELECT  UserName  From  Users  " 

+  "WHERE  (  (  Users . UserName  = 

+  sUserName 

+  "')  AND  (  Users . Password  = 

+  sPassword 

+  "'  )  AND  (  Users . UserType  = 
+  sUserType 


//  execute  the  Query 

ResultSet  resultSet  =  sqlHelper .executeQuery (sUserQuery)  ; 
if  (! resultSet . next  0 )  { 

//  the  database  has  no  results  -  therefore  the  user  is  not 


authenticated 


return  false; 


//  retrieve  the  resultset 

String  sResult  =  resultSet . getString ( 1 ) ; 


//  if  the  username  is  returned 


if  (sResult  !=  null)  { 

//  the  user  has  been  successfully  authenticated 
isAuthenticated  =  sUserName . equals (sResult) ; 

} 

}  catch  (SQLException  sqlE)  { 
sqlE .print StackTr ace ( )  ; 
return  false; 

}  catch  (Exception  e)  { 

e .printStackTrace ( ) ; 
return  false; 


return  isAuthenticated; 


/  *  * 

*  Build  hashtable  from  resultset. 

*/ 

private  static  Hashtable  getFeaturesFromResultSet (ResultSet  resultSet) 
throws  SQLException  { 

Hashtable  hFeatures  =  new  Hashtable (); 

String  sFeatureName  =  null; 

String  sFeatureValue  =  null; 

while  (resultset . next  0 )  { 

SFeatureName  =  resultSet . getString ( 1 ) ; 

SFeatureValue  =  resultSet.getString(2); 
hFeatures .put (sFeatureName,  sFeatureValue) ; 


return  hFeatures; 


/  *  * 

*  Load  from  DomainList  and  Permissions  tables. 

*/ 

public  static  Hashtable  loadDomainList ( )  { 

Hashtable  hFeatures  =  null; 

String  sDomainListQuery  = 

"SELECT  DomainList . DomainAddress ,  Permissions . PermissionName  From 
DomainList,  Permissions  " 

+  "  WHERE  ( DomainList . DomainID  =  Permissions . PermissionID) 


//  execute  the  Query 

Resultset  resultSet  =  sqlHelper.executeQuery (sDomainListQuery) ; 
hFeatures  =  getFeaturesFromResultSet (resultSet) ; 

}  catch  (SQLException  sqlE)  { 
sqlE .printStackTrace ( ) ; 
return  null; 

}  catch  (Exception  e)  { 

e  .printStackTrace ( ) ; 
return  null; 


return  hFeatures; 


/  *  * 

*  Load  from  Users  and  Permissions. 


public  static  Hashtable  loadUserDomainMapping ( )  { 

Hashtable  hFeatures  =  null; 
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AND 


string  sUserDomainQuery  = 

"SELECT  Users . UserName ,  Permissions . PermissionName  " 

+  "FROM  Users,  Permissions,  User_Permission_Xref  " 

+  "  WHERE  (  " 

+  " (User_Permission_Xref . PermissionID  =  Permissions . PermissionID) 
+  " (User_Permission_Xref . User ID  =  Users. UserlD  )  )"; 


try  { 

//  execute  the  Query 

ResultSet  resultSet  =  sqlHelper.executeQuery (sUserDomainQuery)  ; 
hFeatures  =  getFeaturesFromResultSet (resultSet) ; 

}  catch  (SQLException  sqlE)  { 
sqlE .print StackTr ace ( ) ; 
return  null; 

}  catch  (Exception  e)  { 

e  .printStackTrace ( )  ; 
return  null; 

} 


return 


hFeatures; 


/  *  * 

*  Load  from  Permissions  table. 

*/ 

public  static  ArrayList  getListOf Domains ( )  { 

String  sListof DomainsQuery  =  "SELECT  PermissionName  From  Permissions"; 
try  { 

//  execute  the  Query 

ResultSet  resultSet  =  sqlHelper .executeQuery (sListofDomainsQuery) ; 

//  position  to  first  record 

boolean  moreRecords  =  resultSet . next () ; 

//  If  there  are  no  records,  display  a  message 
if  ( (moreRecords)  { 
return  null; 

}  else  { 

ArrayList  listOf Domains  =  new  ArrayList (); 
do  { 

String  domain  =  resultSet . getString ( "PermissionName" ) ; 
listOf Domains . add (domain) ; 

}  while  (resultSet . next  0)  ; 
return  listOf Domains ; 

}  //end  else 

}  catch  (SQLException  sqlE)  { 
sqlE .printStackTrace ( )  ; 
return  null; 

}  catch  (Exception  e)  { 

e  .printStackTrace ( ) ; 
return  null; 


}//end  of  DSMRepositoryHelper 


uinin. helper .  dataaccess  .MetaRepositoryHelper 

package  umm. helper .dataaccess; 

import  umm. entity . beans .* ; 

import  java.sql.*; 
import  java. util.*; 

/  *  * 

*  This  class  performs  functions  associated  with  accessing 

*  the  Meta_Repository  to  retrieve  search  results. 


Creation  date;  (11/15/2001  1:15:26  PM) 
@author;  Nanditha  Nayani  Siram 


*/ 

public  class  MetaRepositoryHelper  { 

private  j ava . util . Hashtable  resultTable; 
private  QueryBean  queryBean; 

/  *  * 

*  Constructor  1 
*/ 

public  MetaRepositoryHelper ( )  { 

super ( ) ; 

} 


/  *  * 

*  Constructor  2 
*/ 

public  MetaRepositoryHelper (QueryBean  newQueryBean)  { 
queryBean  =  newQueryBean; 

} 


/  *  * 

*  Excecute  Query  against  MR  and  return  search  results. 

*/ 

public  Hashtable  getSearchResultTable ( )  throws  java . lang. Exception  { 

SQLHelper  sqlHelper  =  new  SQLHelperO; 

String  searchQuery  =  queryBean . getQuery () ; 

if  (searchQuery  ==  null  ||  searchQuery . equals ("") ) 

throw  new  Exception ( "No  Parameters  Passed  For  Search"); 

ResultSet  resultSet  =  sqlHelper .executeQuery (searchQuery) ; 

//  position  to  first  record 

boolean  moreRecords  =  resultSet . next () ; 

//  If  there  are  no  records,  display  a  message 
if  ( ImoreRecords)  { 

sqlHelper . shutDown ( ) ; 

throw  new  Exception ( "No  Records  Matching  Search  Criteria"); 
}  else  { 

resultTable  =  new  Hashtable (); 

ComponentBean  componentBean  =  null; 

//  get  row  data 
do  { 


String  ID  =  resultSet . getString ( "id" )  ; 

if  (! resultTable . isEmpty ( )  &&  resultTable . containsKey ( ID) )  { 

componentBean  =  (ComponentBean)  resultTable . get ( ID) ; 
FunctionBean  functionBean  =  new  FunctionBean ( ) ; 
functionBean . buildBean (resultSet) ; 
componentBean . addFunctionBeans (functionBean) ; 


}  else 


componentBean  =  new  ComponentBean () ; 

componentBean . buildBean (resultSet)  ; 

FunctionBean  functionBean  =  new  FunctionBean () ; 
functionBean . buildBean (resultSet)  ; 

componentBean . addFunctionBeans (functionBean) ; 
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resultTable . put ( ID,  componentBean) ; 

} 

}  while  (resultSet . next ( ) ) ; 

}  //end  of  else 
sqlHelper . shutDown ( ) ; 
return  resultTable; 

} 

}//end  of  MRHelper 

uimn .  helper .  dataaccess  .  SQLHelper 

package  umm. helper .dataaccess; 

import  java .util .* ; 
import  java.sql.*; 

/  *  * 

*  This  is  the  class  which  serves  as  a  connection  to  the 

*  oracle  database.  It  establises  the  database  connection 

*  and  executes  queries  which  either  select/update  the 

*  tables  of  the  database  as  well  as  execute  stored 

*  procedures. 

*  Creation  date;  (9/14/2001  12:57:07  PM) 

*  @author;  Nanditha  Nayani  Siram 
*/ 

public  class  SQLHelper  { 

private  j ava . sql . Connection  dbconn  =  null; 
private  j ava . sql . Statement  statement  =  null; 

/  *  * 

*  Constructor 
*/ 

public  SQLHelperO  throws  j ava . lang . Exception  { 

// - 

//  Get  Connection  to  database. 

//  The  URL  specifying  the  database  to  which 

//  this  program  connects  using  JDBC 

// - 

String  url  =  "j dbc : oracle ; thin ; @phoenix . cs . iupui . edu ; 152 1 : OS80 " ; 

String  username  =  "nnayani"; 

String  password  =  "nnayani"; 

//  Load  the  driver  to  allow  connection  to  the  database 
try  { 

Class . f orName ( "oracle . j  dbc . driver . Oracle Driver" )  ; 

dbconn  =  DriverManager . getConnection (url ,  username,  password) 

statement  =  dbconn . createStatement () ; 

}  catch  (ClassNotFoundException  cnfex)  { 

System. err . println ( "Failed  to  load  driver."); 
cnfex . printStackTrace () ; 

System. exit ( 1 ) ;  //  terminate  program 

}  catch  (SQLException  sqlex)  { 


System. err . println (" \n  Unable  to  connect  to  Oracle  Server"); 
sqlex. printStackTrace () ; 

System. exit ( 1 ) ;  //  terminate  program 


*  Commit  Transaction 
*/ 

public  final  void  commitTransaction ( )  throws  j ava . lang . Exception  { 
try  { 

dbconn . commit ( ) ; 

}  catch  (SQLException  sqle)  { 
throw  new  Exception ( 

"\n  SQL  Exception  during  commitTransaction  with  message 

sqle . getMessage ( ) ) ; 


*  Execute  a  Query 
*/ 

public  ResultSet  executeQuery (String  query)  throws  j ava . lang . Exception  { 
ResultSet  resultSet  =  null; 


resultSet  =  statement . executeQuery (query) ; 

}  catch  (SQLException  sqle)  { 
throw  new  Exception ( 

"\n  SQL  Exception  during  executeQuery  with  message;"  + 

sqle . getMessage ( ) ) ; 


return  resultSet; 


/  *  * 

*  Return  DB  Connection 
*/ 

public  java . sql . Connection  getDbconnO 
return  dbconn; 


/  *  * 

*  Return  Statement 
*/ 

public  java . sql . Statement  getStatement ( ) 
return  statement; 


*  Turn  off  Auto  Commit  before  initiating  transaction 
*/ 

public  final  void  initiateTransaction ( )  throws  j ava . lang . Exception  { 
try  { 

dbconn . setAutoCommit (false) ; 

}  catch  (SQLException  sqle)  { 
throw  new  Exception ( 

"\n  SQL  Exception  during  initiateTransaction  with  message 
+  sqle . getMessage 0) ; 

} 

} 

/  *  * 

*  Perform  Rollback 


public  void  rollbackTransaction ( )  throws  j ava . lang . Exception  { 
try  { 

dbconn . rollback ( ) ; 

}  catch  (SQLException  sqle)  { 
throw  new  Exception ( 

"\n  SQL  Exception  during  rollbackTransaction  with  message 


+  sqle . getMessage ( ) ) ; 


/  *  * 

*  Set  DB  Connection 
*/ 

public  void  setDbconn (java . sql . Connection  newDbconn)  { 
dbconn  =  newDbconn; 

} 

/  *  * 

*  Set  Statement 
*/ 

public  void  setStatement ( j ava . sql . Statement  newStatement) 
statement  =  newStatement; 

} 

/  *  * 

*  Close  connection 
*/ 

public  void  shutDownO  throws  j ava . lang . Exception  { 


if  (statement  !=  null) 

statement . close ( ) ; 

if  (dbconn  !=  null) 

dbconn . close ( ) ; 

}  catch  (Exception  e)  { 

throw  new  Exception (e . getMessage ()); 


*  Update  DB  Table 
*/ 

public  void  updateTable ( String  updateString)  throws  j ava . lang . Exception 


dbconn . setAutoCommit (false) ; 
statement . executeUpdate (updateString) ; 
dbconn . commit ( ) ; 

}  catch  (SQLException  sqle)  { 
throw  new  Exception ( 

"\n  SQL  Exception  from  function  updateTable  with  message 

sqle . getMessage ( ) ) ; 

} 


uinm .  helper .  dependent .  CreateKey 

package  umm. helper .dependent; 

import  javax . crypto .* ; 
import  java.io.*; 
import  java .security.*; 


*  This  utility  class  is  used  to  generate  secret-keys, 

*  Creation  date:  (10/14/2001  5:09:08  PM) 

*  @author:  Nanditha  Nayani 


public  class  CreateKey 


*  Constructor 


public  CreateKeyO  { 


*  generate  and  Return  Secret-Key. 

*/ 

public  static  SecretKey  getKeyO  { 

SecretKey  desKey  =  null; 
try  { 

Provider  sunjce  =  new  com. sun . crypto . provider . Sun JCE () ; 
Security. addProvider (sunJce) ; 

KeyGenerator  keyGen  =  KeyGenerator . getinstance ( "DES" ) ; 
desKey  =  keyGen . generateKey () ; 

}  catch  (Exception  e)  { 

System. out. println (e) ; 

} 

return  desKey; 


umm . helper . dependent . CryptOb j 

package  umm. helper .dependent; 

import  javax . crypto .* ; 
import  java .security.*; 


*  This  class  provides  the  utility  functions 

*  for  encrypting  and  decrypting  data. 

*  Creation  date;  (10/14/2001  5:09:08  PM) 

*  @author;  Nanditha  Nayani 


public  class  CryptObj  { 

private  Cipher  encryptCipher  =  null; 
private  Cipher  decryptCipher  =  null; 


*  Constructor 
*/ 

public  CryptObj (SecretKey  desKey) 

{ 


Provider  sunjce  =  new  com. sun . crypto . provider . Sun JCE () ; 
Security. addProvider (sunjce)  ; 

//  get  cipher  object  for  encryption 

encryptCipher  =  Cipher . getinstance ( "DES/ECB/PKCS5Padding" 
encryptCipher . init (Cipher .ENCRYPT_MODE,  desKey) ; 

decryptCipher  =  Cipher . getinstance ( "DES/ECB/PKCS5Padding" 
decryptCipher . init (Cipher . DECRYPT_MODE,  desKey)  ; 

} 

catch  (Exception  e) 

{ 

System. out. println (e)  ; 


*  Encrypt  Object 


public  Object  enCryptObj (java . io . Serializable  inObj ) 
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SealedObject  sealObj  =  null; 
try{ 

sealObj  =  new  SealedObject (inObj , encryptCipher) ; 

} 

catch (Exception  e) 

{ 

System. out. println (e)  ; 

} 

return  sealObj ; 

} 

/  *  * 

*  Decrypt  Object 
*/ 

public  Object  deCryptObj (SealedObject  inObj ) 

{ 

Object  thisObj  =  null; 
try{ 


thisObj  =  inObj .getObject (decryptCipher) ; 

} 

catch (Exception  e) 

{ 

System. out. println (e) ; 


} 


return  thisObj; 


} 

}//end  of  CryptObj 


uinin .  helper .  dependent .  MulticastReceiver 

package  umm. helper .dependent; 

import  umm. helper . dependent .* ; 
import  umm. entity . beans .* ; 
import  umm. services .* ; 

import  java.net.*; 
import  java.io.*; 
import  java.util.*; 
import  java.rmi.*; 

import  java . security .* ; 
import  javax . crypto .* ; 

/  *  * 

*  This  class  operates  on  a  Thread,  which  constantly  listens 

*  for  multicast  messages  on  a  MulticastSocket  and  receives 

*  the  incoming  DatagramPackets .  This  thread  utilizes  the 

*  CryptObject  and  ObjectSerializer  Helper  objects  to  decrypt 

*  and  reconstruct  the  multicast  messages  received. 

*  Creation  date:  (10/15/2001  11:50:10  AM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  MulticastReceiver  implements  Runnable  { 

private  InetAddress  groupAddress  =  null; 
private  MulticastSocket  multicastSocket  =  null; 
private  int  port  =  10000; 
private  CryptObj  cryptObject  =  null; 

private  javax . crypto . SealedObject  encryptedRegistryLocation  =  null; 
private  ObjectSerializer  obj Serializer  =  null; 
private  java . lang. String  registryLocation  =  null; 
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public  void  run ( )  { 

try  { 

multicastSocket  =  new  MulticastSocket(port); 
mult least Socket . joinGroup (groupAddress) ; 

System. out. println ("\n  Active  Registry  joined  multicast  group  at  ;  "  + 

groupAddress) ; 

while  (true)  { 

byte [ ]  buffer  =  new  byte [1024]; 

//Receiving  data 

DatagramPacket  dataPacket  =  new  DatagramPacket (buffer , 

buf fer . length) ; 

multicastSocket . receive (dataPacket) ; 

// -  Without  Encryption  - 

//  String  dataString  =  new  String (dataPacket . getData ())  ; 

// -  With  Encryption  - 

byte [ 1  encryptedHHLoc  =  dataPacket.getDataO; 

obj Serializer . setBytes (encryptedHHLoc) ; 

SealedObject  encryptedObject  =  (SealedObject) 
obj Serializer. getObject ( )  ; 

String  dataString  =  (String) 
cryptObject.deCryptObj (encryptedObject) ; 

System. out . println ( "Active  Registry  Received  Encrypted  Multicasted  Headhunter 
Location  ;  "  +  dataString) ; 

try  { 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 
IHeadhunter  hhunter  =  ( IHeadhunter ) 

Naming . lookup (dataString . trim ( ) ) ; 

//Unicast  information  to  headhunter 

hhunter . receiveUnicastCommunication ( registryLocation) ; 
System. out. println (  "Active  Registry  Unicast  to  Headhunter 

"  + 

dataString  +  "  its  Location  "  +  registryLocation) ; 


}  catch  (Exception  e)  { 

System. out. println (e) ; 

} 

}  //end  of  while 

}  catch  (lOException  ioe)  { 

System. out. println (ioe)  ; 

}  //end  of  try-catch 
finally  { 

if  (multicastSocket  !=  null)  { 
try  { 

multicastSocket. leaveGroup (groupAddress) ; 
multicastSocket . close ( ) ; 

}  catch  (lOException  ioe)  { 

System. out. println (ioe) ; 

}  //end  of  try-catch 

}  //end  of  if 
}  //end  of  finally 

}  //end  of  run 

//Constructor 

public  MulticastReceiver ( 
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int  mcastPort, 

AuthenticatedPacket  authPacket, 

String  regLocation)  { 

try  { 

groupAddress  =  InetAddress . getByName (authPacket . getMCAddress ( ) ) ; 
port  =  mcastPort; 

cryptObject  =  new  CryptObj (authPacket . getKey ()) ; 
obj Serializer  =  new  ObjectSerializer ( )  ; 
registryLocation  =  regLocation; 
encryptedRegistryLocation  =  (SealedObject) 
cryptObject.enCryptObj  (registryLocation)  ; 

}  catch  (Exception  e)  { 

System. out. println (e)  ; 

System. exit ( 1 ) ; 

}  //end  of  try-catch 

}  //end  of  Receiver 
}  //end  of  class  MulticastReceiver 


uirnn .  helper .  dependent .  MulticastSender 

package  umm. helper .dependent; 

import  umm. helper . dependent .* ; 
import  umm. entity . beans .* ; 

import  java.net.*; 
import  java . security .* ; 
import  javax . crypto .* ; 

/  *  * 

*  This  class  operates  as  a  Thread  which  executes  periodically. 

*  This  Thread  has  a  connection  to  a  MulticastSocket  to  which  it 

*  keeps  multicasting  DatagramPackets  at  regular  intervals  of  time. 

*  This  thread  utilizes  the  CryptObject  and  ObjectSerializer  Helper 

*  objects  to  multicast  encrypted  serialized  messages. 

*  Creation  date;  (10/15/2001  11:50:10  AM) 

*  @author;  Nanditha  Nayani  Siram 
*/ 


public  class  MulticastSender  implements  Runnable) 


private 
private 
private 
private 
private 
private 
private 
private 
private 
private  Obj 


InetAddress  InetAddress  =  null; 
DatagramPacket  dataPacket  =  null; 
int  port  =  10000; 
byte  ttl  =  (byte)  1; 

String  hostLocation  = 
byte [ ]  buffer; 

MulticastSocket  multicastSocket  =  null; 
long  TPmcast  =  0; 

CryptObj  cryptObject  =  null; 
ectSerializer  obj Serializer  =  null; 


public  void  run ( ) 

{ 

Thread  CurrentThread  =  Thread . currentThread () ; 

try 

{ 

while (true) 

{ 

dataPacket  = 

new  DatagramPacket (buffer, buffer. length, InetAddress , port) ; 
multicastSocket. send (dataPacket, ttl) ; 

System. out . println (" \n  Multicasting  Encrypted  HH  Location  ;  "  + 

hostLocation) ; 

CurrentThread. sleep (TPmcast) ; 


}//end  of  while 

} 

catch ( InterruptedException  ie) { 

System. out .print In (ie . getMessage ( ) ) ; 

}//end  of  try-catch 

catch (SocketException  se) 

{ 

System. out. println (se)  ; 

} 

catch (Exception  e) 

{ 

System. out. println (e)  ; 

}//end  of  try-catch 

}//end  of  run 

public  MulticastSender ( 
long  mcastTime, 
int  mcastPort, 

AuthenticatedPacket  authPacket, 

String  headHunterLoc)  { 

try  { 

TPmcast  =  mcastTime; 

inetAddress  =  InetAddress . getByName (authPacket . getMCAddress ( ) ) ; 
port  =  mcastPort; 
hostLocation  =  headHunterLoc; 

cryptObject  =  new  CryptObj (authPacket .getKeyO); 


// -  Without  Encryption  - 

//  buffer  =  hostLocation . getBytes 0 ; 

// -  With  Encryption - 


//Create  the  encrypted  host  location  by  sealing 

//location  with  secret-key  and  serializing  this  object  for  transmission 

SealedObject  sealedHostLocation  =  (SealedObject) 
cryptObject.enCryptObj (hostLocation) ; 

obj Serializer  =  new  ObjectSerializer ( ) ; 

obj Serializer. setObject (sealedHostLocation) ; 
buffer  =  obj Serializer . getBytes 0; 


multicastSocket  =  new  MulticastSocketO; 
multicastSocket. joinGroup (inetAddress) ; 

System. out . println ( "Headhunter  joined  multicast  group;"  +  inetAddress); 

}  catch  (SocketException  se)  { 

System. out. println (se) ; 

}  catch  (Exception  e)  { 

System. out. println (e) ; 

System. exit ( 1 ) ; 


}}//end  of  class  MulticastSender 

uinm.  helper .  dependent .  ObjectSerializer 

package  umm. helper .dependent; 

import  java.io.*; 

/  *  * 

*  This  ObjectSerializer  class  is  a  mechanism  to 


*  transmit  Java  objects  over  the  network. 

*  It  makes  use  of  the  Java  serialization  mechanism. 

*  Creation  date:  (10/14/2001  5:09:08  PM) 

*  @author:  Nanditha  Nayani  Siram 


public  class  ObjectSerializer { 
Object  myObj ; 


public  ObjectSerializer ( )  { 

super ( ) ; 


public  ObjectSerializer (Object  o) 
setObject (o) ; 


Interprets  the  bytes  as  a  serialized  object 
*/ 

public  ObjectSerializer (byte [ ]  b)  { 
setBytes (b) ; 


Get  the  contained  Object 
*/ 

public  Object  getObjectO  { 
return  myObj ; 


Set  the  contained  Object 
*/ 

public  void  setOb j ect (Ob j ect  o) 
myObj  =  o; 


Serializes  the  contained  object  into  a  byte  array 
*/ 

public  byte  [  ]  getBytesO  { 
try  { 

ByteArrayOutputStream  ostream  =  new  ByteArrayOutputStream (256) ; 

ObjectOutputStream  p  =  new  ObjectOutputStream (ostream) , 
p . wr iteOb j  ect (myObj ) ; 

p . flush ( ) ; 

byte [ ]  rtnVal  =  ostream. toByteArray  ()  ; 
ostream. close  ( )  ; 
return  rtnVal; 

}  catch  (Exception  e)  { 
e .printStackTrace ( ) ; 
return  null; 

} 


Interprets  the  bytes  as  a  serialized  object  and  sets  the  contained  reference 
to  the  unserialized  version  of  the  serialized  object 


public  void  setBytes (byte [ ]  b)  { 
try  { 

ByteArrayInputStream  is  =  new  ByteArrayInputStream (b) ; 
ObjectInputStream  p  =  new  Ob j ectInputStream ( is ) ; 
myObj  =  p . readObject ( ) ; 
is . close ( ) ; 

}  catch  (Exception  e)  { 
e .printStackTrace ( ) ; 


}//  End  class  ObjectSerializer 

uinin .  helper .  dependent .  RequestProcessor 

package  umm. helper .dependent; 

import  umm. entity . beans ; 
import  umm. services ; 

import  java .util . * ; 
import  java.rmi.*; 


*  RequestProcessor  provides  the  glue  in  the  Web  tier 

*  for  holding  the  application  components  together. 

*  It  contains  logic  that  needs  to  be  executed  for  each 

*  request.  RequestProcessor  collaborates  with  the 

*  QueryManager  and  gets  a  Hashtable  of  search  results 

*  from  the  QueryManager  which  it  forwards  to  the  View 

*  ComponentList . j  sp . 

*  Creation  date:  (8/16/2001  1:08:35  PM) 

*  Oauthor:  Nanditha  Nayani 
*/ 

public  class  RequestProcessor  { 

private  java .util . Hashtable  resultTable  =  null; 
private  IQueryManager  qm  =  null; 
private  QueryBean  queryBean  =  null; 


*  RequestProcessor  constructor  comment. 

*/ 

public  RequestProcessor ( )  throws  Exception  { 

String  qmLocation  =  "/ /magellan . cs . iupui . edu : 8500 /QueryManager 
qm  =  (IQueryManager)  Naming. lookup (qmLocation) ; 

System. out. println ("Looked  up  QM"); 


public  void  clearResults ( )  { 

resultTable  =  null; 

} 

public  java .util . Hashtable  getResultTable ( )  throws  Exception  { 

if  (resultTable  ==  null)  { 

resultTable  =  qm. getSearchResultTable (queryBean) , 


return  resultTable; 


public  void  setResultTable (java .util . Hashtable  newResultTable) 
resultTable  =  newResultTable; 


public  QueryBean  getQueryBean ( ) 
return  queryBean; 


public  void  setQueryBean (QueryBean  newQueryBean) 
queryBean  =  newQueryBean; 
resultTable  =  null; 


umm. helper . dependent . UniFramelntrospector 

package  umm. helper .dependent; 

import  j avax . servlet . http .* ; 
import  j ava . lang . ref lect . * ; 
import  java .beans .* ; 
import  j ava. util.*; 


*  This  utility  class  uses  reflection  to  analyze  the  properties 

*  of  an  object  and  retrieve  the  value  corresponding  to  a 

*  specific  attribute. 

*  Creation  date;  (6/11/2001  9:18:51  AM) 

*  @author;  Nanditha  Nayani  Siram 


public  class  UniFramelntrospector 

public  UniFramelntrospector ( )  { 

super ( ) ; 


*  Introspect  Bean  and  return  Property 
*/ 

public  static  Object  getProperty (Object  bean.  String  propertyName) 
throws  UniFrameIntrospectorException  { 

Object  property  =  null; 

Method  method  =  null; 

Object)]  args  =  null; 


Beaninfo  info  =  Introspector . getBeanInf o (bean . getClass ( ) ) ; 
PropertyDescriptor [ ]  pds  =  inf o . getPropertyDescriptors ( ) ; 

for  (int  i  =  0;  pds  !=  null  &&  i  <  pds. length;  i++)  { 

if  (pds [1] . getName (). equals (propertyName) )  { 

method  =  pds [1] . getReadMethod ( ) ; 
break; 

} 

} 

}  catch  ( IntrospectionException  e)  { 

throw  new  UniFrameIntrospectorException ( 

"Error  analyzing  the  bean  class:  "  +  e . getMessage ( ) ) ; 


if  (method  ==  null) 

throw  new  UniFrameIntrospectorException ( 

"Property  "  +  propertyName  +  "  not  found"); 


property  =  method. invoke (bean,  args); 

System. out . println ( "Active  Registry  obtained  UMM  Spec  URL  by  Introspection 
+  property) ; 

}  catch  (Exception  e)  { 

throw  new  UniFrameIntrospectorException ( 
e . getClass ( ) . getName ( ) 

+  "  ;  " 

+  "Failed  to  get  property  " 

+  propertyName 
+  ",  message;  " 

+  e . getMessage 0); 


return  property; 


uinin .  helper .  dependen't .  UniFramelntrospectorException 

package  umm. helper .dependent; 

^  * 

*  Creation  date:  (10/5/2001  12:55:32  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  UniFramelntrospectorException  extends  Exception 
public  UniFramelntrospectorException ( )  { 

super ( ) ; 

} 

public  UniFramelntrospectorException (String  s)  { 
super (s) ; 


umm . helper . dependent . UniFrameSpecif icationParser 

package  umm. helper .dependent; 
import  umm. entity . beans .* ; 


import  j ava . io . lOException; 

import  org . w3c . dom. Document ; 

import  org . w3c . dom. DocumentType ; 

import  org . w3c . dom . NamedNodeMap ; 

import  org. w3c. dom. Node; 

import  org.w3c.dom.NodeList; 

import  org . apache . xerces . parsers . DOMParser ; 

import  java .util . * ; 


*  This  class  is  used  to  parse  a  UniFrame  XML 

*  specification  file  and  construct  an  instance 

*  of  the  ComponentBean . 

*  Creation  date:  (9/14/2001  12:57:07  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 


public  class  UniFrameSpecif icationParser  { 

private  ComponentBean  cbean  =  new  ComponentBean () ; 
private  Vector  functionVector  =  new  Vector (); 
private  boolean  populatedFlag  =  false; 
private  Vector  syntaxVector  =  new  VectorO; 

/  *  * 

*  Constructor 


public  UniFrameSpecif icationParser ( String  uri)  { 

//  Instantiate  your  vendor's  DOM  parser  implementation 
DOMParser  parser  =  new  DOMParser (); 
try  { 

parser. parse (uri) ; 

Document  doc  =  parser . getDocument () ; 

//  Read  the  document  from  the  DOM  tree. 
readNode (doc) ; 

}  catch  (lOException  e)  { 

System. out . println ( "Error  reading  URI;  "  +  e . getMessage ( ) 
}  catch  (Exception  ex)  { 

System. out . println ( "Error  in  parsing;  "  +  ex . getMessage ( ) 
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*  Return  Component  Bean. 

*/ 

public  ComponentBean  getComponentBean ( )  { 

if  (populatedFlag  ==  false)  { 

for  (int  i  =  0;  i  <  functionVector . size ( ) ;  i++)  { 

FunctionBean  fBean  =  new  FunctionBeanO; 
fBean . setid (cbean . getid ( ) ) ; 

fBean . setFunctionName ( (String)  functionVector . get (i) ) ; 
fBean . setSyntacticContract ( (String)  syntaxVector . get (i) ) ; 
cbean . addFunctionBeans (fBean) ; 

} 

populatedFlag  =  true; 

} 

return  cbean; 

} 


/  *  * 

*  Parse  through  XML  tree  using  recursion. 

*/ 

private  void  readNode (Node  node)  { 

if  (node . getNodeName ( ) . equalsIgnoreCase ( "ComponentName" ) )  { 
cbean . setName (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if  (node . getNodeName (). equalsIgnoreCase ( "Description" ) )  { 

cbean . setDescription (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if  (node . getNodeName (). equalsIgnoreCase ( "Function" ) )  { 

functionVector . add (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if  (node . getNodeName (). equalsIgnoreCase ( "ID" ) )  { 

cbean . setid (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if  (node . getNodeName (). equalsIgnoreCase ( "Purpose" ) )  { 

cbean . setFunction (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if 

(node . getNodeName ( ) . equalsIgnoreCase ( "Algorithm" ) )  { 

cbean . setAlgorithm (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if 

(node . getNodeName ( ) . equalsIgnoreCase ( "Complexity" ) )  { 

cbean . setComplexity (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

if 

(node . getNodeName ( ) . equalsIgnoreCase ( "Contract" ) )  { 

syntaxVector . add (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 


if 


(node . getNodeName ( ) . equalsIgnoreCase ( "Technology" ) )  { 

cbean . setTechnology (node . getFirstChild ( ) . getNodeValue ( ) ) ; 


}  else 


if 


(node . getNodeName () .equalsIgnoreCase ( "PreprocessingCollaborators" ) )  { 


cbean . setPreprocessingCollaborators (node . getFirstChild ( ) . getNodeValue ( ) ) ; 

}  else 

(node . getNodeName ( ) . equalsIgnoreCase ( "Mobility" ) )  { 

cbean . setMobility (node . getFirstChild ( ) . getNodeValue ( ) ) ; 


if 


}  else 
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if  (node . getNodeName ( ) . equalsIgnoreCase ( "Availability" ) 

cbean . setAvailability ( 

)  { 

(new  Double (node . getFirstChild ( )  . getNodeValue ( )  ; 

}  else 

1  . doubleValue  ( ) ) ) ; 

if  (node . getNodeName ( ) . equalsIgnoreCase ( "End2EndDelay" ) 

cbean . setEnd2endDelay ( 

)  { 

(new  Double (node . getFirstChild ( )  . getNodeValue ( )  ; 

} 

//  recurse  on  each  child 

NodeList  children  =  node . getChildNodes ( ) ; 
if  (children  !=  null)  { 

1  . doubleValue  ( ) ) ) ; 

for  (int  1=0;  1  <  children . getLength () ;  i++) 
readNode ( children . item  ( 1 ) ) ; 

} 

} 

} 

} 

( 

uinin.  services .  ActiveRegistry 

package  umm. services; 

import  umm. entity . beans ; 
import  umm. helper .dependent. *; 
import  umm. services ; 


import  j ava . rmi . registry ; 
import  java. rmi.*; 
import  j  ava . net . * ; 
import  java .util . * ; 
import  j ava . rmi . server .* ; 

/  *  * 

*  The  ActiveRegistry  class  receives  multicast  messages  from  the  Headhunter 

*  by  using  the  MulticastReceiver  class.  Interaction  with  the  Headhunter  for 

*  passing  its  contact  information  and  component  information  are  done  through 

*  RMI-JRMP.  It  also  communicates  with  the  DomainSecurityManager  for 

*  authentication  purposes  using  RMI-JRMP.  The  ActiveRegistry  uses  the 

*  UniFrameIntrospector  for  the  purpose  of  obtaining  the  UniFrame  specifications 

*  of  the  components  registered  with  it.  It  also  uses  the  UniFrameSpecif icationParser 

*  for  parsing  the  specifications  and  building  instances  of  ComponentBean  objects, 

*  which  it  returns  to  the  Headhunter. 

*  Creation  date:  (11/14/2001  5:09:08  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  ActiveRegistry  extends  UnicastRemoteObject  implements  lActiveRegistry 

{ 

private  int  port  =  9000; 

private  String  userType  =  "Registry"; 

/  *  * 

*  Obtain  URL  List  of  Registered  Components. 

*/ 

private  String  []  listO  { 

String []  listOfURLS  =  null; 
try  { 

listOfURLS  =  Naming . list ("/ /magellan . cs . iupui . edu : 9000 ") ; 

}  catch  ( j ava . rmi . RemoteException  e)  { 


System. out .print In (e . getMessage ( ) ) ; 
}  catch  (Exception  e)  { 

System. out .print In (e . getMessage ( ) ) ; 


return  listOfURLS; 


public  static  void  main (String [ ]  args)  { 

int  rmiRegistryPort  =  9000; 
int  mcastPort  =  10000; 

String  userName  =  "Regl"; 

String  password  =  "Regl"; 

String  domain  =  "Finance"; 

String  activeRegistryLocation  =  "/ /mage 1 Ian . cs . iupui . edu : 8500/ActiveRegistry" 
String  dsmLocation  =  "/ /magellan . cs . iupui . edu : 8500 /DomainSecurityManager"; 


System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

Naming . rebind ( 

activeRegistryLocation, 
new  ActiveRegistry ( 

rmiRegistryPort, 
mcastPort, 
userName , 
password, 
domain, 

activeRegistryLocation, 

dsmLocation) 

)  ; 

System. out. println ("ActiveRegistry  is  ready. ") ; 

}  catch  (Exception  e)  { 

System. out. println ("ActiveRegistry  failed:  "  +  e) ; 


*  The  ActiveRegistry  Constructor 
*/ 

public  ActiveRegistry ( 

int  rmiRegistryPort, 
int  mcastPort, 

String  userName, 

String  password. 

String  domain. 

String  activeRegistryLocation, 
String  dsmLocation) 
throws  RemoteException  { 


String  rmiRegistryLocation  =  ( InetAddress . getLocalHost ( ) ) .toStringO; 
port  =  rmiRegistryPort; 

//Create  the  registry  on  this  host  and  port 
LocateRegistry . createRegistry (port) ; 

rmiRegistryLocation  =  rmiRegistryLocation  +  ":"  +  port; 

System. out. println ("\n  Active  Registry  Created  RMI  Registry  At  :  "  + 
rmiRegistryLocation) ; 

IDomainSecurityManager  dsmanager  = 

( IDomainSecurityManager )  Naming. lookup (dsmLocation) ; 
AuthenticatedPacket  authpacket  =  null; 

System. out. println ("Active  Registry  Contacting  DSM  for  Authentication.") 


authpacket  = 
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dsmanager . authenticationService ( 
userType, 
userName , 
password, 

activeRegistryLocation, 
domain) ; 

System. out . println ( "Active  Registry  Authenticated  by  DSM."); 

MulticastReceiver  mcastReceiver  = 

new  MulticastReceiver (mcastPort,  authpacket, 
activeRegistryLocation)  ; 

Thread  receiverThread  =  new  Thread (mcastReceiver ) ; 
receiverThread. start ( ) ; 


}  catch  (Exception  e)  { 

System. out .println (e . getMessage ( ) ) ; 

} 


}  //end  of  constructor 
/  *  * 

*  Returns  components  to  HH. 

*/ 

public  Hashtable  getComponentData ( )  throws  RemoteException 

{ 

Hashtable  objectTable  =  new  Hashtable () ; 

System. out . println ( "Active  Registry  contacted  by  Headhunter  to  Retrieve  Component 

Data" )  ; 


try 

{ 


information  from 


this  object  by 


String)]  objURL  =  listO; 
for(int  i=0; i<ob jURL . length; i++) 

{ 

System. out . println ( "Active  Registry  gathering  component 
+  objURL [i]  )  ; 

//Registry  looking  up  object  registered  with  it. 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 
Object  obj  =  Naming. lookup (objURL [i] ) ; 

//Obtain  the  location (URL)  of  the  UMMSpecif ication  for 
//introspecting  its  ummSpecif ication  property. 


String  ummSpecURL  =  (String) 
UniFrameIntrospector . getProperty (obj , "ummSpecURL" ) ; 


will  parse  the  XML 
which  it  returns. 


//Call  the  XMLParser  by  passing  this  URL.  The  XML  Parser 
specification 

//and  construct  a  ComponentBean  from  the  specification 


UniFrameSpecif icationParser  xmlDomParser  =  new 
UniFrameSpecif icationParser (ummSpecURL) ; 

ComponentBean  componentBean  = 
xmlDomParser . getComponentBean ( ) ; 

//Add  the  component  to  the  Hashtable 
objectTable .put (objURL [i] , componentBean) ; 
}//end  for 


} 

catch (Exception  e)  { 
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System. out .print In (e . getMessage ( ) ) ; 

} 

//Once  the  Hashtable  is  filled  return  the  hashtable 
return  ob jectTable; 

} 

}//end  of  Active  Registry 


uinin.  services  .DomainSecurityManager 

package  umm. services; 

import  umm. entity . beans ; 
import  umm. helper .dependent. *; 
import  umm. helper . dataaccess ; 

import  j  ava . net . * ; 
import  java .util . * ; 
import  java.rmi.*; 
import  j ava . rmi . server ; 
import  j ava . rmi . registry ; 
import  j ava . security . Principal ; 
import  java . security . acl . * ; 

import  sun . security . acl ; 
import  j  avax . crypto . * ; 

/  *  * 

*  This  class  implements  IDomainSecurityManager  interface. 

*  The  DSM  performs  the  functions  of  generating  secret-keys 

*  for  the  domains  using  the  CreateKey  helper  class. 

*  It  authenticates  the  principals  against  the  DSM_Repository 

*  with  the  help  of  the  DSMRepositoryHelper  and  distributes  the 

*  secret-keys  and  multicast  addresses  to  Headhunters  and 

*  Active  Registries.  The  communication  between  the  parties 

*  is  based  on  RMI-JRMP. 

*  Creation  date:  (9/14/2001  12:57:07  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 


public  class  DomainSecurityManager  extends  UnicastRemoteObject  implements 
IDomainSecurityManager 
{ 


private  static  final  String  securityOwnerString  =  "DomainSecurityManager"; 
private  static  final  String  aclldentif ier  =  "DomainSecurityACL" ; 


private  static  final  Principal  securityOwner  =  new 
Principallmpl (securityOwnerString)  ; 

private  static  final  Acl  domainACL  =  new  Acllmpl (  securityOwner , aclldentif ier); 


private 

private 

private 

private 

private 

private 


static  Hashtable  userdomainMapping  =  null; 
static  Hashtable  domainList  =  null; 

static  Hashtable  HHAddressAllocTable  =  new  Hashtable (); 
static  Hashtable  registeredHHTable  =  new  Hashtable (); 
static  Hashtable  keyTable  =  new  Hashtable (); 
static  Random  rand  =  new  Random (); 


/  *  * 

*  Construtor 
*/ 


public  DomainSecurityManager ( )  throws  RemoteException  { 
super ( ) ; 
try  { 

createACLEntries  () ; 
generateSecretKeys () ; 

}  catch  ( DomainSecurityManagerException  e)  { 
System. out. println  (e) ; 
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} 

} 

public  static  void  main (String [ ]  args)  { 

String  dsmLocation  =  " / /magellan . cs . iupui . edu : 8500 /DomainSecurityManager " ; 
try  { 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

Naming. rebind (dsmLocation,  new  DomainSecurityManagerO); 

System. out . println ( "DomainSecurityManager  "  +  dsmLocation  +  "  is  ready."); 
}  catch  (Exception  e)  { 

System. out . println ( "DomainSecurityManager  failed;  "  +  e) ; 

} 

} 

/  *  * 

*  Return  List  of  Registered  HHs. 

*/ 

public  j ava . util . ArrayList  getHHListForDomain ( String  domainName ) 
throws  RemoteException  { 

System. out. println ("DSM  Contacted  by  QM  for  HH  List  for  :  "  +  domainName  +  " 

Domain" ) ; 

ArrayList  hhList  =  new  ArrayList (); 

Enumeration  e  =  registeredHHTable . keys ( ) ; 

while  (e .hasMoreElements ( ) )  { 

String  key  =  (String)  e . nextElement ( ) ; 

String  value  =  (String)  registeredHHTable . get ( key) ; 
if ( (value) . equalsIgnoreCase (domainName) ) 

{ 

hhList. add (key) ; 

}//end  if 
} / /end  while 
return  hhList; 

} 

/  *  * 

*  authenticate  principal  against  DSM_Repository 
*/ 

private  static  Principal  retrieveUser ( 

String  userType, 

String  userName, 

String  password) 

throws  DomainSecurityManagerException  { 

//  load  user  from  database 
boolean  userExists  = 

DSMRepositoryHelper.authenticateUser (userType,  userName,  password) ; 

//  if  not  found,  throw  exception 
if  (  luserExists)  { 

throw  new  DomainSecurityManagerException ( 

"User  "  +  userName  +  "  failed  authentication.", 
null) ; 

} 

System. out . println ( "DSM  authenticated  "  +  userName); 

//  Create  the  Principal  object 

Principal  user  =  new  Principallmpl (userName) ; 

return  user; 

} 

/  *  * 
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*  Get  key  for  given  domain. 

*/ 

private  static  SecretKey  getKey (String  domainName ) 
throws  DomainSecurityManagerException  { 
return  (SecretKey)  keyTable . get (domainName ) ; 


/  *  * 

*  Get  multicast  address  for  user. 

*/ 

private  static  String  getDomainAddressForUser ( 
String  userType, 

String  userName, 

String  password. 

String  location. 

String  domainName) 

throws  DomainSecurityManagerException  { 
String  domainAddress  =  null; 


//  Create  the  Principal  object 

Principal  user  =  retrieveUser (userType ,  userName,  password); 

Permission  permission  =  new  Permissionlmpl (domainName) ; 
if  (isUserAuthenticated (user,  permission))  { 

domainAddress  =  pickDomainAddress (userType,  domainName,  location) 
}  else  { 

throw  new  DomainSecurityManagerException ( 

"User  "  +  userName  +  "  is  not  authorized  for  the  domain  " 


domainName , 

} 


null)  ; 


+ 


System. out. println ("DSM  authorized  "  +  userName  + 

"  and  allocated  multicast  address 


return 


domainAddress ; 


+  domainAddress) ; 


/  *  * 

*  Pick  multicast  address  for  HH/AR. 

*/ 

private  static  String  pickDomainAddress ( 

String  userType, 

String  domainName, 

String  location) 

throws  DomainSecurityManagerException  { 

String  domainAddress  =  null; 

if  ( (domainList  !=  null)  &&  (domainList . containsValue (domainName )) )  { 


//If  a  registry  requests  an  address  check  if  there  are  headhunters  in  this 
//domain.  Randomly  pick  an  address  in  this  domain  to  which  headhunters 
//already  multicast, 
if  ( (userType . equals ( "Registry" ) ) 

&&  (HHAddressAllocTable . containsValue (domainName) ) )  { 

Enumeration  e  =  HHAddressAllocTable . keys () ; 

Vector  thisVector  =  new  Vector (); 
while  (e .hasMoreElements ( ) )  { 

String  key  =  (String)  e . nextElement ( ) ; 
if  (  (  (String) 

HHAddressAllocTable . get ( key) ) . equals (domainName ) ) 

thisVector .add (key) ; 


int  size  =  thisVector . size () ; 
if  (size  >  0)  { 

int  num  =  rand. nextint (size)  ; 

domainAddress  =  (String)  thisVector . get (num) ; 

} 

} 

//If  a  headhunter  requests  an  address  randomly  pick  an  address  in  this 


169 


domain  to 

//allocate  to  headhunter, 
else  { 


Enumeration  e  =  domainList . keys ( ) ; 

Vector  thisVector  =  new  Vector (); 
while  (e .hasMoreElements ( ) )  { 

String  key  =  (String)  e . nextElement ( ) ; 
if  (((String)  domainList . get ( key )). equals (domainName ) ) 
thisVector .add (key) ; 


int  size  =  thisVector . size () ; 
if  (size  >  0)  { 

int  num  =  rand . nextint ( size ) ; 

domainAddress  =  (String)  thisVector . get (num) ; 

} 

//Add  the  allocated  address  to  the  headhunterList  if  not  already 

added. 


if  ((domainAddress  !=  null) 

&&  (userType . equals ( "HeadHunter" ) ) 

&&  ! (HHAddressAllocTable . containsKey (domainAddress) ) )  { 

HHAddressAllocTable .put (domainAddress,  domainName) ; 
registeredHHTable .put (location,  domainName) ; 

System. out. println ("Registered  "  +  (String) 
registeredHHTable . get (location)  + 

"  Headhunter  located  at  "  +  location) ; 


} 


} 

}  else  { 

throw  new  DomainSecurityManagerException ( 

"No  Such  Domain  Exists;  "  +  domainName, 
null) ; 

} 

return  domainAddress; 

} 


/  *  * 

*  Verify  user  authentication 
*/ 

private  static  final  boolean  isUserAuthenticated ( 

Principal  user. 

Permission  domain)  { 

//  Just  use  the  java . security . acl .ACL  class  to  handle  this 
return  domainACL . checkPermission (user ,  domain); 


/  *  * 

*  add  ACL  Entries. 

*/ 

private  static  void  addAclEntry (String  userName,  String  domain) 
throws  DomainSecurityManagerException  { 

//  Create  the  Principal  object 

Principal  user  =  new  Principallmpl (userName) ; 

//  create  a  new  Acl  entry  for  this  user 
AclEntry  newAclEntry  =  new  AclEntrylmpl (user) ; 

//  initialize  some  temporary  variables 

Permission  permission  =  new  Permissionlmpl (domain) ; 

//  add  the  permission  to  the  aclEntry 
newAclEntry . addPermission (permission) ; 

try  { 

//  add  the  aclEntry  to  the  ACL  for  the  securityOwner 
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domainACL.addEntry (securityOwner,  newAclEntry) ; 


}  catch  (NotOwnerException  noE)  { 

throw  new  DomainSecurityManagerException ( " In  addAclEntry" ,  noE) ; 


/  *  * 

*  Remote  method  called  by  HH/AR. 

*/ 

public  AuthenticatedPacket  authenticationService ( 

String  userType, 

String  userName, 

String  password. 

String  location. 

String  domain) 

throws  RemoteException  { 

AuthenticatedPacket  authPacket  =  new  AuthenticatedPacket (null,  null); 
try  { 

authPacket . setMCAddress ( 

getDomainAddressForUser ( 
userType, 
userName , 
password, 
location, 
domain) ) ; 

authPacket . setKey (getKey (domain) ) ; 

}  catch  (Exception  e)  { 

System. out. println (e)  ; 

} 

return  authPacket; 

} 


/  *  * 

*  Create  ACL  Entries. 

*/ 

private  static  void  createACLEntries ( )  throws  DomainSecurityManagerException  { 


System. out. println ("DSM  Creating  ACL  Entries.  "); 


try  { 

//  loads  all  the  domains  addresses  associated  with 
//  various  domains  into  a  hashtable 
if  (userdomainMapping  ==  null)  { 

//  initialize  the  jdbc  helper  class 
DSMRepositoryHelper . initialize  () ; 

userdomainMapping  =  DSMRepositoryHelper . loadUserDomainMapping ( ) ; 


if  (userdomainMapping  !=  null)  { 

Enumeration  e  =  userdomainMapping. keys () ; 
while  (e .hasMoreElements ( ) )  { 

String  key  =  (String)  e . nextElement ( ) ; 
String  domainName  =  (String) 

userdomainMapping . get ( key)  ; 

addAclEntry ( key,  domainName); 

System. out. println ( 

"Added  ACLEntry  for  User  =  "  +  key  + 


Domain  =  "  +  domainName) ; 


}  //while 

}  //if (userdomainMapping  !=  null) 
}  //if  (userdomainMapping==null ) 


if  (domainList  ==  null)  { 

domainList  =  DSMRepositoryHelper . loadDomainList () ; 
System. out. println ("\n  Loaded  DomainList"); 

} 
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}  catch  (Exception  e)  { 

throw  new  DomainSecurityManagerException ( "Error  in  init  method",  e) 


^  * 

*  Generates  secret  Keys. 

*/ 

private  static  void  generateSecretKeys ( )  throws  DomainSecurityManagerException  { 

System. out. println ("DSM  Generating  Secret-Keys  For  Domains.  "); 
try  { 

ArrayList  listOf Domains  =  DSMRepositoryHelper . getListOf Domains () ; 

for  (int  i  =  0;  i  <  listOf Domains . size () ;  i++)  { 

String  domainName  =  (String)  listOf Domains . get ( i ) ; 

SecretKey  key  =  CreateKey . getKey ( ) ; 
keyTable .put (domainName,  key); 

System. out. println ("DSM  Created  Secret-Key  for  Domain  :  "  + 

domainName) ; 

}  //end  for 

}  catch  (Exception  e)  { 

throw  new  DomainSecurityManagerException ( 

"DSM  failed  to  generate  keys."  +  e, 
null) ; 

} 

} 


}//end  of  DomainSecurityManager 


uinin.  services .  DomainSecurityManager 

package  umm. services; 

public  class  DomainSecurityManagerException  extends  Exception 

{ 

private  String  message  =  null; 
private  Exception  exception  =  null; 

public  DomainSecurityManagerException ( String  smessage.  Exception  ex) 

{ 

//  store  the  passed  in  values  as  class  variables 
message  =  smessage; 
exception  =  ex; 

} 

public  String  getMessageO 

{ 

//  return  the  message  to  the  user 
return  message; 

} 

public  void  printStackTrace ( ) 

{ 

//  output  the  message  &  print  the  StackTrace 
System. out. print In (  message) ; 
exception. printStackTrace ()  ; 


umm . services . Headhunter 

package  umm. services; 

import  umm. entity . beans .* ; 
import  umm. helper .dependent. *; 
import  umm. services .* ; 
import  umm. helper . dataaccess .* ; 
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import  j  ava . net . * ; 
import  java .util . * ; 

import  java.rmi.*; 
import  j ava . rmi . server ; 
import  j ava . rmi . registry ; 

import  j  ava . security . * ; 
import  java.io.*; 

/  *  * 

*  This  class  implements  the  IHeadhunter  interface. 

*  The  Headhunter  class  interacts  with  the  QueryManager 

*  and  DomainSecurityManager  using  RMI-JRMP.  The  Headhunter 

*  uses  the  MulticastSender  to  multicast  encrypted  messages 

*  to  ActiveRegistry  services.  The  Headhunter  also  communicates 

*  with  the  ActiveRegistry  services  through  unicast  RMI-JRMP  for 

*  the  purpose  of  obtaining  the  component  information  as  a  Hashtable 

*  of  ComponentBean  objects.  The  HeadHunter  persists  this  component 

*  information  to  the  Meta_Repository  and  uses  the  MetaRepositoryHelper 

*  for  the  purpose  of  performing  searches  against  the  repository. 

*  The  SQL  query  for  the  searches  is  obtained  from  the  QueryBean  which 

*  is  propagated  to  the  Headhunter  by  the  QueryManager. 

*  Creation  date:  (10/15/2001  11:50:10  AM) 

*  Oauthor:  Nanditha  Nayani 
*/ 

public  class  Headhunter  extends  UnicastRemoteObject  implements  IHeadhunter 

{ 

private  Hashtable  registryTable  =  new  Hashtable  (); 
private  java . lang. String  userType  =  "HeadHunter"; 

/  *  * 

*  Remote  method  invoked  by  QM. 

*/ 

public  Hashtable  performSearch (QueryBean  querybean)  throws  RemoteException  { 

System. out. println ("Processing  Query  Request  From  Query  Manager"); 

MetaRepositoryHelper  srchEngine  =  new  MetaRepositoryHelper (querybean) ; 
try  { 

return  srchEngine . getSearchResultTable () ; 

}  catch  (Exception  e)  { 

System. out. print In (e)  ; 
return  null; 


/  *  * 

*  Create  the  MR. 

*/ 

private  static  void  createMetaRepository ( )  throws  Exception  { 


String  componentCreateString  = 
"CREATE  TABLE  COMPONENT ( "  + 

"ID  VARCHAR2 (150)  PRIMARY  KEY,"  + 
"NAME  VARCHAR2 (100) , "  + 
"DESCRIPTION  VARCHAR2 (1000) , "  + 
"FUNCTION  VARCHAR2 (500) , "  + 
"ALGORITHM  VARCHAR2 (200) , "  + 
"COMPLEXITY  VARCHAR2  (30)  ,  "  + 
"DOMAIN  VARCHAR2 (30) , "  + 
"TECHNOLOGY  VARCHAR2 ( 30 ) , "  + 
"COLLABORATORS  VARCHAR2 ( 2 0 0 ) , "  + 
"END2ENDDELAY  NUMBER ( 9 ), "  + 
"AVAILABILITY  NUMBER ( 9 ), "  + _ 
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"MOBILITY  VARCHAR2 (5) ) "; 

String  functionCreateString  = 

"CREATE  TABLE  FUNCTION ("  + 

"ID  VARCHAR2 (150)  NOT  NULL,"  + 

"FUNCTION_NAME  VARCHAR2 ( 2 50 )  NOT  NULL,"  + 

"SYNTACTIC_CONTRACT  VARCHAR2 ( 2 50 )  NOT  NULL,"  + 

"CONSTRAINT  pkl  PRIMARY  KEY ( ID, FUNCTION_NAME, SYNTACTIC_CONTRACT) , "  + 
"CONSTRAINT  fkl  FOREIGN  KEY (ID)"  + 

"REFERENCES  COMPONENT ( ID)  ON  DELETE  CASCADE)"; 

SQLHelper  sqlEngine  =  new  SQLHelper ( ) ; 
sqlEngine .updateTable ( componentCreateString) ; 
sqlEngine .updateTable (functionCreateString) ; 
sqlEngine . shutDown ( ) ; 

} 

public  static  void  main (String [ ]  args)  { 
long  mcastTime  =  5000; 

String  headhunterLocation  =  " / /magellan . cs . iupui . edu : 8500 /HeadHunter " ; 
String  dsmLocation  =  "/ /magellan . cs . iupui . edu : 8500 /DomainSecurityManager " ; 
int  mcastPort  =  10000; 

String  userName  =  "HeadHuntl"; 

String  password  =  "HeadHuntl"; 

String  domain  =  "Finance"; 

if (args . length  >  0) 

mcastTime  =  Long . parseLong (args [ 0 ]) ; 

try  { 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

Naming . rebind ( 

headhunterLocation, 
new  Headhunter ( 
mcastTime , 

mcastPort, 
userName , 
password, 
domain, 

headhunterLocation, 
dsmLocation) ) ; 

System. out. println ("HeadHunter  is  ready."); 

}  catch  (Exception  e)  { 

System. out . println ( "HeadHunter  failed;  "  +  e) ; 

} 

} 

/  *  * 

*  Constructor 
*/ 

public  Headhunter ( 
long  mcastTime, 
int  mcastPort, 

String  userName, 

String  password. 

String  domain. 

String  headhunterLocation, 

String  dsmLocation) 
throws  RemoteException  { 

System. out. println ("\n  HeadHunter  activated  at  "  +  headhunterLocation); 
try  { 

Headhunter . createMetaRepository ( )  ; 

System. out. println ( "MetaRepository  Created. ") ; 
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}  catch  (Exception  e)  { 

//Ignore  if  repository  already  created 
System. out. println ( "MetaRepository  Created. ") ; 

} 


try  { 

System. out . println ( "Headhunter  Contacting  DSM  for  Authentication."); 

IDomainSecurityManager  dsmanager  = 

( IDomainSecurityManager )  Naming. lookup (dsmLocation) ; 
AuthenticatedPacket  authpacket  =  null; 
authpacket  = 

dsmanager . authenticationService ( 
userType, 
userName , 
password, 

headhunter Location, 
domain) ; 

System. out. println ("Headhunter  Authenticated  by  DSM"); 

MulticastSender  mcastSender  = 

new  MulticastSender (mcastTime ,  mcastPort,  authpacket, 

headhunterLocation) ; 

Thread  senderThread  =  new  Thread (mcastSender ) ; 
senderThread. start ( )  ; 

}  catch  (Exception  e)  { 

System. out .println (e . getMessage ( )  )  ; 

} 

}  //end  of  constructor 
/  *  * 

*  Persist  component  information  obtained  from  AR 

*  into  MR. 

*/ 

private  void  populateMetaRepository (String  regLoc)  { 

//  retrieve  component  info 
try  { 

SQLHelper  sqlEngine  =  new  SQLHelperO; 

System. out. println ("Headhunter  contacting  Registry  at  "  +  regLoc  +  "  for 
registered  services  data."); 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

lActiveRegistry  Reg  =  ( lActiveRegistry)  Naming . lookup ( regLoc . trim ()) ; 

Hashtable  CompData  =  (Hashtable)  Reg. getComponentData ( ) ; 

System. out. println ("Headhunter  obtained  registered  services  data  from  : 

+  regLoc) ; 

Enumeration  e  =  CompData . elements () ; 
while  (e .hasMoreElements ( ) )  { 

ComponentBean  componentBean  =  (ComponentBean)  e . nextElement ( ) ; 
try  { 

componentBean . persistBean (sqlEngine) ; 

}  catch  (Exception  ex)  { 

//If  the  component  already  exists  in  MR  then  ignore. 

} 

System. out. println ("Headhunter  persisted  component  "  + 
componentBean . getid ( )  +  "  into  MR."); 

} / /end  while 

sqlEngine . shutDown ( ) ; 
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}  catch  (Exception  ex)  { 

System. out . println ( "HH  exception  "  +  ex) 

} 

1 

/  *  * 

*  Remote  method  invoked  by  AR  to  pass  its  location  information 
*/ 

public  void  receiveUnicastCommunication (String  regLoc)  throws  RemoteException  { 

System. out . println ( "Headhunter  received  unicast 
+  regLoc) ; 

registryTable .put (regLoc,  (new  j ava . util . Date ( ) 
populateMetaRepository (regLoc) ; 

1 

communication  from  Registry  at  :  " 

)  )  ; 

; 

}//end  of  HeadHunter 

uinin.  services .  lActiveRegistry 

package  umm. services; 

import  java.rmi.*; 
import  java .util . * ; 

/  *  * 

*  This  is  the  interface  for  the  ActiveRegistry  service. 

*  This  interface  publishes  the  following  method: 

*  getComponentData ( ) :  This  method  is  invoked  by  the  Headhunter 

*  to  retrieve  component  information  from  the  ActiveRegistry. 

*  Creation  date:  (9/14/2001  12:57:07  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  interface  lActiveRegistry  extends  Remote 

{ 

public  Hashtable  getComponentData ( )  throws  RemoteException; 

} _ 


umm. services . IDomainSecurityManager 

package  umm. services; 

import  umm. entity . beans .* ; 

import  java .util . * ; 
import  java.rmi.*; 

/  *  * 

*  This  is  the  interface  for  the  DomainSecurityManager  service. 

*  This  interface  publishes  two  methods: 

*  getHHListForDomain :  This  method  is  invoked  by  the  QueryManager . 

*  The  purpose  of  this  method  is  to  return  a  list  of  registered 

*  Headhunters  for  a  particular  domain  to  the  QueryManager. 

*  authenticationService :  This  method  is  invoked  by  the  Headhunter 

*  and  ActiveRegistry  components  to  authenticate  themselves  with 

*  the  DSM. 

*  Creation  date:  (3/16/02  9:07:49  PM) 

*  Oauthor: 

*/ 

public  interface  IDomainSecurityManager  extends  java . rmi .Remote { 

public  ArrayList  getHHListForDomain ( String  domainName)  throws  RemoteException; 
public  AuthenticatedPacket  authenticationService (String  userType,  String  userName, 
String  password.  String  contactLocation,  String  domain)  throws  RemoteException; 

} 


umm. services . IHeadhunter 

package  umm. services; 
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import  umm. entity . beans ; 

import  java.rmi.*; 
import  java .util . * ; 
import  java . security. * ; 
import  java.io.*; 

/  *  * 

*  This  is  the  interface  for  the  Headhunter  service. 

*  This  interface  publishes  the  following  methods: 

*  perf ormSearch :  This  method  is  invoked  by  the  QueryManager 

*  to  propagate  a  search  query. 

*  receiveUnicastCommunication :  This  method  is  invoked  by  the 

*  ActiveRegistry  to  inform  the  Headhunter  of  its  location. 

*  Creation  date:  (9/14/2001  12:57:07  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  interface  IHeadhunter  extends  Remote  { 

public  Hashtable  performSearch (QueryBean  querybean)  throws  RemoteException; 
public  void  receiveUnicastCommunication (String  regLoc)  throws  RemoteException; 


umm. services . QueryManager 

package  umm. services; 

import  umm. entity . beans .* ; 
import  umm. services .* ; 

import  j  ava . net . * ; 
import  java .util . * ; 

import  java.rmi.*; 
import  j ava . rmi . server .* ; 
import  j ava . rmi . registry .* ; 


/  *  * 

*  This  class  implements  the  IQueryManager  interface. 

*  The  QueryManager  class  propagates  the  search  query 

*  as  a  QueryBean  object  to  the  list  of  Headhunter 

*  components  obtained  from  DomainSecurityManager  and 

*  returns  search  results  to  the  RequestProcessor . 

*  The  interaction  between  these  components  is  based 

*  on  RMI-JRMP. 

*  Creation  date:  (10/15/2001  11:50:10  AM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  QueryManager  extends  UnicastRemoteObject  implements  IQueryManager 

{ 

private  IDomainSecurityManager  dsm  =  null; 

/  *  * 

*  Constructor 
*/ 

public  QueryManager ( String  dsmLocation)  throws  RemoteException  { 
try  { 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

dsm  =  (IDomainSecurityManager)  Naming. lookup (dsmLocation) ; 

}  catch  (Exception  e)  { 

System. out .print In (e . getMessage  ( ) ) ; 

} 

}  //end  of  constructor 
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/  *  * 

*  Remote  Method  invoked  by  RequestProcessor  to 

*  retrieve  search  results. 

*/ 

public  Hashtable  getSearchResultTable (QueryBean  querybean) 
throws  RemoteException  { 

System. out. println ("QM  Requested  to  propagate  Search  Query."); 

Hashtable  resultTable  =  new  Hashtable (); 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

ArrayList  hhList  =  dsm.getHHListForDomain(querybean.getDomain()); 

System. out . println ( "QM  obtained  regsitered  headhunter  list  from  DSM  for  Domain  "  + 

querybean . getDomain ( ) ) ; 

for  (int  i  =  0;  i  <  hhList . size () ;  i++) 


try  { 


String  hhLocation  =  (String)  hhList . get ( i ) ; 

IHeadhunter  hh  =  ( IHeadhunter )  Naming. lookup (hhLocation . trim ()) ; 

System. out . println ( "QM  Propagating  Query  To  HH  At  "  +  hhLocation); 
Hashtable  thisResultTable  =  hh.performSearch (querybean) ; 

System. out . println ( "QM  Obtained  Results  from  HH  At  "  +  hhLocation); 

Enumeration  e  =  thisResultTable . keys () ; 
while  (e .hasMoreElements ( ) )  { 

String  id  =  (String)  e . nextElement ( ) ; 

ComponentBean  cbean  =  (ComponentBean) 

thisResultTable . get (id) ; 

resultTable .put (id,  cbean); 

}  //end  while 
}  catch  (Exception  e)  { 

//Ignore  exception  and  move  on  to  next  headhunter. 


}  //end  for 
return  resultTable; 


public  static  void  main (String [ ]  args) 

{ 


String  dsmLocation  =  " / /magellan . cs . iupui . edu ; 8500 /DomainSecurityManager " ; 

String  qmLocation  =  "/ /magellan . cs . iupui . edu : 8500 /QueryManager" ; 

try 


} 

catch 

{ 

} 


System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

Naming . rebind  (qmLocation,  new  QueryManager(dsmLocation)); 
System. out. println  ("QueryManager  is  ready."); 

(Exception  e) 

System. out. println  ("QueryManager  failed;  "  +  e) ; 


}//end  of  QueryManager 
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uinin.  tests  .AccountServer 

package  umm. tests; 

import  j ava . rmi . server ; 
import  java. rmi.*; 

^  * 

*  This  is  the  test  service  component.  The  class 

*  specifies  the  ummSpecURL  property  and  has 

*  a  getter  which  return  the  URL. 

*  Creation  date:  (9/14/2001  12:57:07  PM) 

*  Oauthor:  Nanditha  Nayani  Siram 
*/ 

public  class  AccountServer  extends  UnicastRemoteObject  implements  lAccountServer { 
private  String  ummSpecURL  = 

public  AccountServer ( String  newUMMSpecURL)  throws  RemoteException { 
ummSpecURL  =  newUMMSpecURL; 

} 

public  String  getUmmSpecURL ( )  throws  RemoteException  { 
return  ummSpecURL; 

} 


public  void  javaDeposit (float  argl) throws  RemoteException  {  } 
public  void  javaWithdraw (float  argl)  throws  RemoteException  {  } 
public  float  j avaBalance ( )  throws  RemoteException!  return  0;} 

public  static  void  main (String [ ]  args)  { 

String  bindingName  =  "/ /magellan . cs . iupui . edu : 9000 /AccountServer"  +  args[0]; 
String  ummSpecUrl  =  "/home/nnayani/ummspecs/ummspec"  +  args[l]  +  ".xml"; 


try  { 

System. setSecurityManager (new  RMISecurityManager ( ) ) ; 

Naming . rebind (bindingName ,  new  AccountServer (ummSpecUrl) ) ; 

System. out. println ("Account  Server  :  "  +  bindingName  +  "  is  ready."); 
}  catch  (Exception  e)  { 

System. out. println ("Account  Server  failed:  "  +  e) ; 


umm . tests . URDSClient 

package  umm. tests; 

import  umm. entity . beans .* ; 
import  umm. helper .dependent. *; 

import  java .util . * ; 

/  *  * 

*  This  is  a  Test  Application  Client. 

*  The  client  issues  several  different  types  and 

*  queries  via  the  Request  Processor. 

*  Creation  date;  (3/17/02  5:40:28  AM) 

*  @author;  Nanditha  Nayani  Siram 
*/ 

public  class  URDSClient  { 

/  *  * 

*  urdsClientDriver  constructor  comment. 

*/ 

public  URDSClient 0  { 


super ( ) ; 


*  Insert  the  method's  description  here. 

*  Creation  date;  (3/17/02  5:55:09  AM) 

*  Sparam  args  j ava . lang . String [ ] 

*/ 

public  static  void  main (String [ ]  args)  { 

URDSClient  urdsClient  =  new  URDSClient ( ) ; 


//Test  Que 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 

QueryBean 


queryBeanl  = 
queryBean2  = 
queryBeanS  = 
queryBeanl  = 
queryBean5  = 
queryBeanO  = 
queryBean?  = 
queryBeanS  = 
queryBeanO  = 
queryBeanlO 


urdsCli 
urdsCli 
urdsCli 
urdsCli 
urdsCli 
urdsCli 
urdsCli 
urdsCli 
urdsCli 
=  urdsCl 


ent . Queryl ( )  ; 
ent . Query2 ( )  ; 
ent . Query3 ( )  ; 
ent . Queryl ( )  ; 
ent . Query5 ( )  ; 
ent . QueryO ( )  ; 
ent . Query? ( )  ; 
ent . QueryS ( )  ; 
ent . Query9 ( )  ; 
lent . QuerylO  ( ) 


ArrayList  queryList  =  new  ArrayListO; 
queryList . add (queryBeanl )  ; 
queryList . add (queryBean2 )  ; 

queryList. add (queryBean3)  ; 
queryList . add (queryBeanl )  ; 
queryList. add (queryBean5)  ; 
queryList. add (queryBeanO)  ; 
queryList . add (queryBean? )  ; 
queryList . add (queryBeanS )  ; 
queryList. add (queryBean9)  ; 
queryList . add (queryBeanlO )  ; 

long  counter=0; 
long  timer=0; 

//Iterate  10  times  through  10  queries  (10  *  10  =100  queries) 
for(int  j=0 ; j<10 ; j++) 

{ 

for(int  i=0; i<queryList .size ( ) ; i++) 

( 

//Increment  counter  for  each  new  query  request. 

counter++; 

try  { 

//Get  each  new  query 

QueryBean  queryBean  =  (QueryBean)  queryList.get(i); 
System. out .println (queryBean . getQuery ( )  +  "\n"); 

//Instantiate  RequestProcessor  and  pass  it  the  query. 

RequestProcessor  reqProcessor  =  new  RequestProcessor () ; 
reqProcessor . setQueryBean (queryBean) ; 

//starting  the  timer  before  query  progagation. 

long  startTime  =  System. currentTimeMillis () ; 

//Actual  call  to  propagate  client  query. 

Hashtable  resultTable  =  reqProcessor . getResultTable () ; 
//Ending  the  timer. 

long  endTime  =  System. currentTimeMillis () ; 

//Computing  the  net  time  for  the  query  servicing  so  far 
timer  =  timer  +  (endTime  -  startTime) ; 

urdsClient. printResults (resultTable) ; 


}  catch  (Exception  e)  { 

System. out. println (e) ; 


}//end  for 
}//end  iteration 

long  avgServiceTime  =  timer/counter; 

System. out. println ("Number  of  iterations  of  Client  Queries  Services  =  "  H 
counter) ; 

System. out. println ("Avergae  time  taken  for  servicing  a  Client  Query  =  "  + 
avgServiceTime) ; 


/  *  * 

*  Print  Results. 

*/ 

public  void  printResults (Hashtable  resultTable)  { 

if  (resultTable  !=  null) 

{ 

Enumeration  e  =  resultTable . keys () ; 
while (e .hasMoreElements ( ) ) 

{ 

String  key  =  (String)  e . nextElement ( ) ; 

ComponentBean  cbean  =  (ComponentBean)  resultTable . get (key) 
System. out .println (cbean . getid ( ) ) ; 


System. out. print In ("- 


public  QueryBean  QuerylO  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" )  ; 
return  queryBean; 

} 

public  QueryBean  Query2()  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" ) ; 
queryBean . setAvai lability Flag (true) ; 
queryBean . setAvailabilityConstraint ( "<" )  ; 
queryBean . setAvailabilityValue ( 100 ) ; 
return  queryBean; 

} 

public  QueryBean  QuerySO  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" )  ; 
queryBean . setComponentName ( "Account" ) ; 
return  queryBean; 


public  QueryBean  Query! ()  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" )  ; 
queryBean . setComponentDescription ( "Account  Management" 
return  queryBean; 


public  QueryBean  QuerySO  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" )  ; 
queryBean . setComplexity ("0(1)  " )  ; 
return  queryBean; 


public  QueryBean  Query6()  { 

QueryBean  queryBean  =  new  QueryBean (); 


queryBean . setDomain ( "Finance  ) ; 
queryBean . setEnd2endDe lay Flag (true) ; 
queryBean . setEnd2endDelayConstraint ( "<" )  , 
queryBean . setEnd2endDelayValue (50 ) ; 
return  queryBean; 


public  QueryBean  Query? ()  { 

QueryBean  queryBean  =  new  QueryBean (); 
queryBean . setDomain ( "Finance" ) ; 
queryBean . setFunctionNames ("deposit  withdraw" 
return  queryBean; 


public  QueryBean  Query8()  { 

QueryBean  queryBean  =  new  QueryBean () 
queryBean . setDomain ( "Finance" ) ; 
queryBean . setMobility ( "yes" ) ; 
return  queryBean; 

} 

public  QueryBean  Query9()  { 

QueryBean  queryBean  =  new  QueryBean () 
queryBean . setDomain ( "Finance" ) ; 
queryBean . setTechnology ( " Java-RMI " ) ; 
return  queryBean; 

} 

public  QueryBean  QuerylOO  { 

QueryBean  queryBean  =  new  QueryBean () 
queryBean . setDomain ( "Finance" ) ; 
queryBean . setAlgorithms ( "add  sub" ) ; 
return  queryBean; 

} 

}//end  of  URDSClient 


UniFrameQuery . jsp 

<html> 

<html> 

<head> 

<meta  http-equiv="PRAGiyiA"  content="NO-CACHE"> 

</head> 

<%@  page  import=" java .util . %> 

<%@  page  isErrorPage=" false"  error Page="error . j sp"%> 

<body  bgcolor  =  #F8F7D9> 

<form  name="queryFilterForm"  method="post"  action="ProcessUniFrameQuery . j sp"> 

<table  width="774"  border="0"  cellspacing="l"  cellpadding="0"> 

<tr> 

<td  bgcolor="#CCCCCC"  valign="top"  height="19"  colspan="5"  > 

<b>  Search  By  Component  Details  </b> 

</td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="0"  width="104"></td> 

<td  width="137"></td> 

<td  width=" 60 "></td> 

<td  width="277"></td> 

<td  width="184"></td> 

<td  width="5"></td> 

</tr> 

<tr  valign="top"> 


<td  height="21"  colspan="2"><b>Domain</b></td> 


<td  valign="top  colspan="4"  height=  21"> 

<select  name="domain"> 

<option  value="Finance"  selected>Finance</option> 

<option  value= "Manufacturing" >Manufacturing</ opt ion> 
</select> 

</td> 

</tr> 

<tr> 

<td  height="37"  valign="top"  colspan="2"><b>Component  Name 
(Enter  Keywords ) </b></td> 

<td  colspan="3"  valign="top"  height="37"> 

<input  type="text"  name="componentName"  size="80"  value=""> 

</td> 

<td  width="5"  height="37"></td> 

</tr> 

<tr> 

<td  height="40"  valign="top"  colspan="2"><b>Component  Description  <br> 
(Enter  Keywords ) </b>  </td> 

<td  colspan="3"  valign="top"  height="40"> 

<input  type="text"  name="componentDescription"  size="80"  value=""> 
</td> 

<td  width="5"  height="40"></td> 

</tr> 


<td  height="37"  valign="top"  colspan="2"> 

<p><b>Function  Names<br> 

</b><b> (Enter  Keywords)  </b></p> 

</td> 

<td  colspan="3"  valign="top"  height="37"> 

<input  type="text"  name="functionNames"  size="80"  value=""> 

</td> 

<td  width="5"  height="37"></td> 

</tr> 

<tr> 

<td  bgcolor="#CCCCCC"  valign="top"  height="19"  colspan="5"  ><b>Search  By  Functional 
Attributes 

</b></td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="38"  valign="top"  colspan="2"><b>Desired  Algorithms  <br> 

(Enter  Keywords ) </b>  </td> 

<td  colspan="3"  valign="top"  height="38"> 

<input  type="text"  name="algorithms"  size="80"  value=""> 

</td> 

<td  width="5"  height="38"></td> 

</tr> 

<tr> 

<td  height="40"  valign="top"  colspan="2"><b>Desired  Complexity  <br> 

(Enter  Keywords)  </b></td> 


<td  colspan="3"  valign="top"  height="40"> 

<input  type="text"  name="complexity"  size="80"  value=""> 
</td> 


<td  width="5"  height="40"></td> 

</tr> 

<tr  valign="top"> 

<td  height="30"  colspan="2"><b>Technology</b></td> 

<td  valign="top"  colspan="4"> 

<select  name="technology"> 

<option  value=""  selected>None</option> 

<option  value=" Java-RMI "> Java-RMI</option> 

<option  value="CORBA">CORBA</option> 

<option  value="Voyager">Voyager</option> 

</select> 

</td> 

</tr> 

<tr> 

<td  bgcolor="#CCCCCC"  valign="top"  height="19"  colspan="5"  ><b>Search  By 
Auxiliary  Atributes</b></td> 

<td  width="5"></td> 

</tr> 

<tr  valign="top"> 

<td  height="30"  colspan="2"><b>Mobility</b></td> 

<td  valign="top"  colspan="4"> 

<select  name="mobility"> 

<option  value="No"  selected>No</option> 

<option  value="Yes">Yes</option> 

</select> 

</td> 

</tr> 

<tr  valign="top"> 

<td  bgcolor="#CCCCCC"  colspan="5"  valign="top"  height="19"  ><b>Search  By 
QOS  Metrics</b></td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="15"  valign="top"  bgcolor="#CCCCCC"  width="104"><b>Select</b></td> 

<td  colspan="2"  valign="top"  bgcolor="#CCCCCC"><b>QOS  Parameter</b></td> 

<td  valign="top"  bgcolor="#CCCCCC"  width="277"><b>Constraints</b></td> 

<td  valign="top"  bgcolor="#CCCCCC"  width="184"><b>Preferences</b></td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="41"  valign="top"  width="104"> 

<input  type="checkbox"  name="qosMetric"  value="end2endDelay"> 

</td> 

<td  colspan="2"  valign="top">  <b>End  To  End  Delay</b>  </td> 

<td  valign="top"  width="277"> 

< select  name="end2endDelayConstraint"> 

<option  value="None"  selected>None</option> 

<option  value="=">=</option> 

<option  value="<">&lt; </option> 

<option  value=">">&gt; </option> 

<option  value="<=">&lt; =</option> 

<option  value=">=">&gt; =</option> 

</select> 

<input  type="text"  name="end2endDelayValue"  size="20"  value=""> 


<td  valign="top"  width="184"> 

< select  name="end2endDelayPref erence"> 

<option  value="None"  selected>None</option> 

<option  value="Descending">Max</option> 

<option  value="Ascending">Min</option> 

<option  value="With">With</option> 

<option  value="Random">Random</option> 

<option  value="First">First</option> 

</select> 

</td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="41"  valign="top"  width="104"> 

<input  type="checkbox"  name="qosMetric"  value="availibility"> 

</td> 

<td  colspan="2"  valign="top">  <b>Availability</b></td> 

<td  valign="top"  width="277"> 

< select  name="availabilityConstraint"> 

<option  value="None"  selected>None</option> 

<option  value="=">=</option> 

<option  value="<">&lt; </option> 

<option  value=">">&gt; </option> 

<option  value="<=">&lt; =</option> 

<option  value=">=">&gt; =</option> 

</select> 

<input  type="text"  name="availabilityValue"  size="20"  value=""> 

</td> 

<td  valign="top"  width="184"> 

< select  name="availabilityPref erence"> 

<option  value="None"  selected>None</option> 

<option  value="Descending">Max</option> 

<option  value="Ascending">Min</option> 

<option  value="With">With</option> 

<option  value="Random">Random</option> 

<option  value="First">First</option> 

</select> 

</td> 

<td  width="5"></td> 

</tr> 

<tr  valign="top"> 

<td  bgcolor="#CCCCCC"  colspan="5"  valign="top"  height="19"  >  <b>Specify 
Policies</b></td> 

<td  width="5"></td> 

</tr> 

<tr> 

<td  height="18"  colspan="6"  valign="top"  bgcolor="#CCCCCC"><b>Search  Scoping 
Policies</b></td> 

</tr> 

<tr> 

<td  height="35"  valign="top"  colspan="2"><b>Max  Upper  Bound  Of  Offers  To 
Return</b>  </td> 

<td  colspan="3"  valign="top"  height="35"> 

<input  type="text"  name="numOf fers"  size="80"  value=""> 

</td> 
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<td  width="5"  height="35"></td> 

</tr> 

<tr> 

<td  height="22"  colspan="6"  valign="top"  bgcolor="#CCCCCC"><b>Function  Scoping 
Policies</b></td> 

</tr> 

<tr> 

<td  height="36"  valign="top"  colspan="2"><b>Min  Number  Of  QOS  Metrics  To 
Match</b>  </td> 

<td  colspan="3"  valign="top"  height="36"> 

<input  type="text"  name="numMetrics"  size="80"  value=""> 

</td> 

<td  width="5"  height="36"></td> 

</tr> 

</table> 

<p  align="center"> 

<input  type="submit"  name="SubmitForm"  value="Perform  Search"> 

<input  type="reset"  name="Submit2"  value="Reset  Form"> 

</p> 

</ form> 

</body> 

</html> 


ProcessUnif rameQuery . j  sp 

<%@  page  isErrorPage="false"  errorPage="error . j sp"%> 

< j  sp : useBean  id="reqProcessor"  class="umm. helper . dependent . Request Processor" 
scope=" session"  /> 

<jsp:useBean  id="queryBean"  class="umm. entity .beans . QueryBean"  scope="session"  /> 
< j  sp : set Property  name="queryBean"  property=" * " /> 


String [ ]  qosMetrics  =  request . getParameterValues ( "qosMetric" ) ; 
if (qosMetrics  !=  null) 

{ 

for(int  i  =  0 ; i<qosMetrics . length; i++) 

{ 

if (qosMetrics [i] .equals ( "end2endDelay" )  ) 

queryBean . setEnd2endDe lay Flag (true) ; 
else 

if (qosMetrics [i] .equals ("availability") ) 
queryBean . setAvai lability Flag (true) ; 

} 

} 

%> 

<%  reqProcessor . setQueryBean (queryBean) ;  %> 

< j  sp : forward  page="componentList . j  sp"  /> 


Componen'tLis't .  j  sp 

<html> 

<head> 

<meta  http-equiv="PRAGMA"  content="NO-CACHE"> 

</head> 

<body  bgcolor  =  #F8F7D9> 

<%@  page  import=" java .util . *"  %> 

<%@  page  import="umm. entity .beans . ComponentBean"  %> 

<%@  page  import="umm. entity .beans . FunctionBean"  %> 

<%@  page  import="umm. entity .beans . QueryBean"  %> 

< j  sp : useBean  id=" reqProcessor"  class="umm. helper . dependent . Request Processor" 
scope=" session"  /> 

<%@  page  isErrorPage=" false"  error Page="error . j sp"%> 


<table  width="100%  border="0  cellspacing="l"  cellpadding="0  height=  83  > 

<tr> 

<td  bgcolor="#CCCCCC"  colspan="4"  valign="top"  > 

<b>URDS  Search  Results  </b> 

</td> 

</tr> 

<tr> 

<td  valign="top"  bgcolor="#CCCCCC"><b>Component-ID</b></td> 

<td  valign="top"  bgcolor="#CCCCCC"><b>Component  Name</b></td> 

<td  valign="top"  bgcolor="#CCCCCC"><b>Component  Detail s</b></td> 

</tr> 


Hashtable  resultTable  =  reqProcessor . getResultTable () ; 
if  (resultTable  !=  null) 


Enumeration  e  =  resultTable . keys () ; 
if (e . hasMoreElements ( ) ) 

{ 

while (e .hasMoreElements ( ) ) 


String  key  =  (String)  e . nextElement ( ) ; 

ComponentBean  componentBean  =  (ComponentBean)  resultTable . get (key) ; 


<td  valign="top"  height="32"><a 

href="componentDetail . j  sp?id=<%=componentBean . getid ( ) %>"><%=componentBean . getid ( ) %></a></t 
d> 

<td  valign="top"><a 

href="componentDetail . j  sp?id=<%=componentBean . getid ( ) %>"><%=componentBean . getName ( ) %></a>< 
/td> 

<td  valign="top"><a  href="componentDetail . j  sp?id=<%=componentBean . getid ( ) %>"> 

Component  Details</a></td> 

</tr> 

<% 

} / /end  while 

}//end  of  if  e .hasMoreElements 
else 
{ 

throw  new  Exception ( "No  Results  Matching  Search  Criteria"); 

}//if  it  does  not  have  elements 


throw  new  Exception ( "No  Results  Matching  Search  Criteria"); 
}//if  resultTable  is  null 


</table> 

<br> 


<a  href  =  "UniFrameQuery . j sp">Search  Home  </a> 
</body> 

</html> 


Componen'tDe'tail .  jsp 

<html> 

<head> 
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<meta  http-equiv="PRAGMA"  content="NO-CACHE"> 

</head> 

<body  bgcolor  =  #F8F7D9> 

<%@  page  import=" java .util . %> 

<%@  page  import="umm. entity .beans . ComponentBean"  %> 

<%@  page  import="umm. entity .beans . FunctionBean"  %> 

<%@  page  import="umm. entity .beans . QueryBean"  %> 

<%@  page  isErrorPage="false"  errorPage="error . j sp"%> 

< j sp : useBean  id="reqProcessor"  class="umm. helper . dependent . Request Processor" 
scope=" session"  /> 


Hashtable  resultTable  =  reqProcessor . getResultTable () ; 
if  (resultTable  !=  null) 

{ 

String  id  =  request . getParameter ( "id" ) ; 

ComponentBean  componentBean  =  (ComponentBean)  resultTable . get (id) ; 

%> 

<table  width="100%"  border="0"  cellspacing="0"  cellpadding="0"  height="530"> 

<tr> 

<td  bgcolor="#CCCCCC"  colspan="3"  height="24"  ><b> 

Component  Details  Summary  </b></td> 

</tr> 

<tr  valign="top"> 

<td  colspan="2"  height="27"><b>Name</b></td> 

<td  width=" 92 9"  height="27 "><%=componentBean . getName ( ) %></td> 

</tr> 

<tr  valign="top"> 

<td  width="202"  valign="top"  nowrap><b>Description</b></td> 

<td  valign="top"  colspan="2"> 

<textarea  name="projectDescription"  rows="3"  cols="40" 
onFocus=" JavaScript : this . blur ( ) "><%=componentBean . get Description ( ) %></textarea> 

</td> 

</tr> 

<tr  valign="top"> 

<td  colspan="3"  height="17"  valign="top"  bgcolor="#CCCCCC"  ><b>Computational 
Attribute s</b></td> 

</tr> 

<tr  valign="top"> 

<td  height="18"  colspan="2"  valign="top"  ><b>ID</b></td> 

<td  valign="top"  width="929"  ><%=componentBean . getid ( ) %></td> 

</tr> 

<tr  valign="top"> 

<td  height="20"  colspan="3"  valign="top"  bgcolor="#CCCCCC"  ><b>Coope rating 
Attribute s</b></td> 

</tr> 

<tr  valign="top"> 

<td  height="22"  colspan="2"  valign="top"  ><b>Pre-Processing  <br> 

Collaborator (s) </b></td> 

<td  valign="top"  width="929"  >  <%=componentBean . getPreprocessingCollaborators ( ) %> 
</td> 

</tr> 

<tr  valign="top"> 

<td  height="20"  colspan="3"  valign="top"  bgcolor="#CCCCCC"  ><b>Auxillary 
Attribute s</b></td> 

</tr> 

<tr  valign="top"> 

<td  height="22"  colspan="2"  valign="top"  ><b>Mobility</b></td> 

<td  valign="top"  width="929"  >  <%=componentBean . getMobility ( ) %>  </td> 

</tr> 

<tr  valign="top"> 

<td  height="18"  colspan="3"  valign="top"  bgcolor="#CCCCCC"  ><b>QOS  Metrics</b></td> 
</tr> 

<tr  valign="top"> 

<td  height="18"  colspan="2"  valign="top"  ><b>End  To  End  Delay</b></td> 

<td  valign="top"  width="929"  >  <%=componentBean . getEnd2endDelay ( ) %>  </td> 

</tr> 

<tr  valign="top"> 
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<td  height="22"  colspan="2"  valign="top"  ><b>Availability</b></td> 

<td  valign="top"  width="929"  >  <%=componentBean . getAvailability ( ) %>  </td> 

</tr> 

<tr  valign="top"> 

<td  height="20"  colspan="3"  valign="top"  bgcolor="#CCCCCC"  ><b>Functional 
Attribute s</b></td> 

</tr> 

<tr  valign="top"> 

<td  height="22"  colspan="2"  valign="top"  nowrap  ><b>Technology</b></td> 

<td  valign="top"  nowrap  width="929"  ><%=componentBean . getTechnology ( ) %></td> 
</tr> 

<tr  valign="top"> 

<td  height="20"  colspan="2"  valign="top"  ><b>Algorithms</b></td> 

<td  valign="top"  width="929"  ><%=componentBean . getAlgorithm ( ) %></td> 

</tr> 

<tr  valign="top"> 

<td  height="20"  colspan="2"  valign="top"  ><b>Complexity</b></td> 

<td  valign="top"  width="929"  ><%=componentBean . getComplexity ( ) %></td> 

</tr> 

<tr  valign="top"> 

<td  height="85"  colspan="3"  valign="top"  > 

<table  width="100%"  border="0"  cellpadding="0"  cellspacing="0"> 

<tr> 

<td  valign="top"  height="26"  bgcolor="#CCCCCC"><b>Function</b></td> 

<td  valign="top"  bgcolor="#CCCCCC"><b>Syntactic  Contract</b></td> 

</tr> 

<% 

Vector  functionVector  =  componentBean . getFunctionBeanList ( ) ; 
int  size  =  0; 

if ( ! functionVector . isEmpty ( ) ) 

{ 

size  =  functionVector . size  0  ; 
for(int  j=0 ; j<size; j++)  { 

FunctionBean  functionBean  = (FunctionBean)  functionVector .elementAt (j ) ; 

%> 

<tr> 

<td  valign="top">  <%=functionBean . getFunctionName ( ) %> 

</td> 

<td  valign="top">  <%=functionBean . getSyntacticContract ( ) %> 

</td> 

</tr> 

<%  }  //end  of  for 

}//end  of  if 
%> 

</table> 

</td> 

</tr> 

</table> 

<% 

}//end  if  (results  !=  null) 

%> 

<br> 

<a  href  =  "UniFrameQuery . j sp">Search  Home  </a> 

<br> 

<a  href  =  "componentList . j sp">Back  To  Component  List  </a> 

</body> 

</html> 


Error . jsp 

<html> 

<head> 

<meta  http-equiv="PRAGMA"  content="NO-CACHE"> 

</head> 

<body  bgcolor  =  #F8F7D9  text  =  #098D3A> 

<%@  page  isErrorPage="true"  %> 

<table  width="100%"  border="0"  cellspacing="0"  cellpadding="l"  align="center"> 
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